Hi,
This mail can lead to all sorts of flamewars, hunting with pitchforks etc., but what the hell... :)
Don't know for you, but to me Inkscape seems to be inside the <1.0 loop forever, whereas people all around effectively use it for solving Real Life (C)(R)(tm) tasks. Yes, it is unbearably slow, it cannot work as a standalone prepress tool and so on and so forth. Nevertheless, it's real tool, not toy. That is, in a way the current <1.0 versioning quite misrepresents Inkscape and its features. Lately Hugin (which is a panorama making tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
This would be another way to deal with the roadmap that we don't really follow anyway.
/me ducks
Alexandre
2009/9/30 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
That is, in a way the current <1.0 versioning quite misrepresents Inkscape and its features. Lately Hugin (which is a panorama making tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
I think the date-based version scheme is boring :) and it doesn't tell when important features are added.
The reason why there is no 1.0 is because 1.0 was intended to be a milestone of full SVG 1.1 support, which we might never achieve. A better approach would be to set more realistic major version milestones.
Here are my candidates for major version milestones: - fast Cairo based renderer - hardware acceleration using OpenVG - live vector effects replace Boolean operations, offset, etc. - rich text support (e.g. hyphenation, subscript and superscript, paragraphs, underlines) in the text tool - basic animation
Regards, Krzysztof
On Wed, 2009-09-30 at 20:46 +0200, Krzysztof Kosiński wrote:
2009/9/30 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
That is, in a way the current <1.0 versioning quite misrepresents Inkscape and its features. Lately Hugin (which is a panorama making tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
I think the date-based version scheme is boring :) and it doesn't tell when important features are added.
The reason why there is no 1.0 is because 1.0 was intended to be a milestone of full SVG 1.1 support, which we might never achieve.
If we never achieve full 1.1 support I think I'll shoot myself. Seriously, if we are limiting ourselves to the SVG standard, yet no one is pushing to achieve it, what is the point of that limitation?
Perhaps we should make it mandatory that at least 1 of our SoC spots each year goes toward implementing some piece needed to be more compliant. It's not fun, it's not exciting, it's not really glamorous either, but it will push that major project goal forward.
Cheers, Josh
-----Original Message----- From: Joshua A. Andler [mailto:scislac@...400...] Sent: woensdag 30 september 2009 23:40 To: Krzysztof Kosiński Cc: Inkscape Devel List; Alexandre Prokoudine Subject: Re: [Inkscape-devel] versioning scheme
If we never achieve full 1.1 support I think I'll shoot myself. Seriously, if we are limiting ourselves to the SVG standard, yet no one is pushing to achieve it, what is the point of that limitation?
Perhaps we should make it mandatory that at least 1 of our SoC spots each year goes toward implementing some piece needed to be more compliant. It's not fun, it's not exciting, it's not really glamorous either, but it will push that major project goal forward.
It can be fun. I've had fun making a couple of testsuite compliance tests pass. There's quite a number of tests that fail; I found it quite rewarding when I could turn one fail into a pass. http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html One of the cool things is that it doesn't require UI-coding which is tedious at best. No use cases, no discussions on what shortcuts you need, and no bugs from users that click different than you do. Simply very well defined small/large projects :-)
I would really like to have this testresult website updated every day. Just to bring it up on the list again: I think we reeeeaaalllly should get this website updated regularly. I cannot offer hardware, hope someone else can.
Ciao, Johan
Wed, 30 Sep 2009 23:58:05 +0200 J.B.C.Engelen@...1578... kirjoitti:
It can be fun. I've had fun making a couple of testsuite compliance tests pass. There's quite a number of tests that fail; I found it quite rewarding when I could turn one fail into a pass. http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html One of the cool things is that it doesn't require UI-coding which is tedious at best. No use cases, no discussions on what shortcuts you need, and no bugs from users that click different than you do. Simply very well defined small/large projects :-)
I would really like to have this testresult website updated every day. Just to bring it up on the list again: I think we reeeeaaalllly should get this website updated regularly. I cannot offer hardware, hope someone else can.
I could provide automatical daily updates. I looked into the test suite and managed to run the test cases, but I can't figure out how I'm supposet to set up that web frontend. Please provide instructions.
Besides, with all that javascript, the site takes quite a while to render as it is. I'd suspect that when it's updated daily, the amount of results grows fast and it'll become really big & slow page. IMO it would be best to have a static, pre-built page. Hiding unchanged results and displaying a couple most recent changes would be nice, too. That's a whole another discussion, though.
-----Original Message----- From: Niko Kiirala [mailto:niko@...1267...] Sent: Thursday, October 01, 2009 13:15 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] versioning scheme
Wed, 30 Sep 2009 23:58:05 +0200 J.B.C.Engelen@...1578... kirjoitti:
I would really like to have this testresult website updated
every day.
Just to bring it up on the list again: I think we
reeeeaaalllly should
get this website updated regularly. I cannot offer hardware, hope someone else can.
I could provide automatical daily updates. I looked into the test suite and managed to run the test cases, but I can't figure out how I'm supposet to set up that web frontend. Please provide instructions.
This is great news! I'm not an expert on setting up websites, but I'm sure someone can help with that. A solution could be to do the tests daily on your machine, and automatically put that on a webpage that is hosted where inkscape.org is hosted? (i.e. the daily script would replace a file on inkscape.org server).
I think the biggest problem at this moment is hardware. Once we have a system running daily tests, it will not be hard to find someone who likes to work on displaying the results on a website with a fancy look :-)
(solution for the many 'new' testresults that are not really new and that need manual intervention: use perceptualdiff)
Ciao, Johan
J.B.C.Engelen@...1578... wrote:
(solution for the many 'new' testresults that are not really new and that need manual intervention: use perceptualdiff)
This is indeed a good point, and there are (were?) some problems with perceptualdiff and transparency (it didn't take it into account when comparing colors). So if you encounter any problems, I have a patch lying around for an old version of perceptualdiff that should do the trick.
Niko Kiirala wrote:
...
I would really like to have this testresult website updated every day. Just to bring it up on the list again: I think we reeeeaaalllly should get this website updated regularly. I cannot offer hardware, hope someone else can.
I could provide automatical daily updates. I looked into the test suite and managed to run the test cases, but I can't figure out how I'm supposet to set up that web frontend. Please provide instructions.
That would be absolutely great. It's done using GWT and you can just "compile" the project in gsoc-testsuite/ResultViewer and then upload the result. It then expects the json output to be in the same directory. If you need any help, just ask.
As for running the tests themselves, I think it should be fine under Linux, but under Windows it is recommended to compile Inkscape as a console application if you want to run the tests unattended (prevents some, but still not all, dialog boxes in case of crashes).
Besides, with all that javascript, the site takes quite a while to render as it is. I'd suspect that when it's updated daily, the amount of results grows fast and it'll become really big & slow page. IMO it would be best to have a static, pre-built page. Hiding unchanged results and displaying a couple most recent changes would be nice, too. That's a whole another discussion, though.
You are completely right. Originally I did it this way because I wanted to try out some interactive stuff, but I never got around to that and the amount of results is indeed quite large. Someone who is handy with scripts might be able to create a simple script to analyze the json and generate at least something similar to what is shown now (but restricted to the last couple of weeks or something).
2009/10/1 Jasper van de Gronde <th.v.d.gronde@...528...>:
You are completely right. Originally I did it this way because I wanted to try out some interactive stuff, but I never got around to that and the amount of results is indeed quite large. Someone who is handy with scripts might be able to create a simple script to analyze the json and generate at least something similar to what is shown now (but restricted to the last couple of weeks or something).
Python to the rescue! http://docs.python.org/library/json.html
Then open an XHTML website template and merge the results in using DOM manipulation. http://docs.python.org/library/xml.dom.minidom.html
Regards, Krzysztof
Thu, 01 Oct 2009 14:03:01 +0200 Jasper van de Gronde <th.v.d.gronde@...528...> kirjoitti:
That would be absolutely great. It's done using GWT and you can just "compile" the project in gsoc-testsuite/ResultViewer and then upload the result. It then expects the json output to be in the same directory. If you need any help, just ask.
Thanks, I managed to build the result viewer.
The site is now up at http://auriga.mine.nu/inkscape/ It _should_ update daily, showing the status of SVN trunk. If everything works as it should, the results for today will appear in approximately six hours.
Do we have any automatic build server? I thought on sf there is something like this. On that can run a "make rendertest" as well.
Adib. ---
2009/9/30 <J.B.C.Engelen@...1578...>:
-----Original Message----- From: Joshua A. Andler [mailto:scislac@...400...] Sent: woensdag 30 september 2009 23:40 To: Krzysztof Kosiński Cc: Inkscape Devel List; Alexandre Prokoudine Subject: Re: [Inkscape-devel] versioning scheme
If we never achieve full 1.1 support I think I'll shoot myself. Seriously, if we are limiting ourselves to the SVG standard, yet no one is pushing to achieve it, what is the point of that limitation?
Perhaps we should make it mandatory that at least 1 of our SoC spots each year goes toward implementing some piece needed to be more compliant. It's not fun, it's not exciting, it's not really glamorous either, but it will push that major project goal forward.
It can be fun. I've had fun making a couple of testsuite compliance tests pass. There's quite a number of tests that fail; I found it quite rewarding when I could turn one fail into a pass. http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html One of the cool things is that it doesn't require UI-coding which is tedious at best. No use cases, no discussions on what shortcuts you need, and no bugs from users that click different than you do. Simply very well defined small/large projects :-)
I would really like to have this testresult website updated every day. Just to bring it up on the list again: I think we reeeeaaalllly should get this website updated regularly. I cannot offer hardware, hope someone else can.
Ciao, Johan
Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Oct 1, 2009, at 7:15 AM, the Adib wrote:
Do we have any automatic build server? I thought on sf there is something like this. On that can run a "make rendertest" as well.
We should probably look into https://build.opensuse.org/
Also if someone wants to set up an automated build server, I'd recommend CruiseControl.
W dniu 30 września 2009 23:39 użytkownik Joshua A. Andler <scislac@...400...> napisał:
If we never achieve full 1.1 support I think I'll shoot myself. Seriously, if we are limiting ourselves to the SVG standard, yet no one is pushing to achieve it, what is the point of that limitation?
I think that's a non sequitur. We limit ourselves to SVG so that other programs might use drawings made with Inkscape. Even a program that can only output paths is useful - the goal of complying with SVG is not eventually supporting the entirety of it, but being compatible with other SVG programs. Support for the entire SVG 1.1 specification is important if we want to use Inkscape to edit files created with other applications, but it doesn't affect the utility of Inkscape as a content creation program.
A nice step towards SVG 1.1 compliance would be to put the rendering tests in the trunk and integrate them with 'make check' (or 'waf check', shortly). And fixing the unit tests so that they don't fail.
Regards, Krzysztof
On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
That is, in a way the current <1.0 versioning quite misrepresents Inkscape and its features. Lately Hugin (which is a panorama making tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
+1 I hate version numbers. Anything to make them go away makes me happier.
--Ted
On Wed, 2009-10-07 at 19:36 -0400, Ted Gould wrote:
On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
That is, in a way the current <1.0 versioning quite misrepresents Inkscape and its features. Lately Hugin (which is a panorama making tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
+1 I hate version numbers. Anything to make them go away makes me happier.
+1 I just went to the Hugin page to see that it was how I thought. I really do like that scheme much better thank our current one.
On Wed, 2009-10-07 at 17:21 -0700, Joshua A. Andler wrote:
On Wed, 2009-10-07 at 19:36 -0400, Ted Gould wrote:
On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
That is, in a way the current <1.0 versioning quite misrepresents Inkscape and its features. Lately Hugin (which is a panorama making tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
+1 I hate version numbers. Anything to make them go away makes me happier.
+1 I just went to the Hugin page to see that it was how I thought. I really do like that scheme much better thank our current one.
Let me clarify, I'd say YEAR.INCREMENTING_NUMBER_STARTING_AT_ZERO
On Wed, Oct 07, 2009 at 07:07:58PM -0700, Joshua A. Andler wrote:
On Wed, 2009-10-07 at 17:21 -0700, Joshua A. Andler wrote:
On Wed, 2009-10-07 at 19:36 -0400, Ted Gould wrote:
On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
That is, in a way the current <1.0 versioning quite misrepresents Inkscape and its features. Lately Hugin (which is a panorama making tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
+1 I hate version numbers. Anything to make them go away makes me happier.
+1 I just went to the Hugin page to see that it was how I thought. I really do like that scheme much better thank our current one.
Let me clarify, I'd say YEAR.INCREMENTING_NUMBER_STARTING_AT_ZERO
A compromise that retains but augments our current numbering scheme could be:
YEAR.SVG_COMPLIANCE.INCREMENTAL_NUMBER
So for example, we'd have:
2008.0.46 2009.0.47 2010.0.48 2010.0.49 ... 2010.1.00
Retains the same meaning and history of our current numbering scheme, plus makes the leftmost number more appealing to the wider userbase.
(I'm just throwing this idea out there, not advocating for it; I've no problems with our current numbering scheme, and am not really active enough in development these days to warrant having an opinion. But hey, unpainted bike shed!)
Bryce
I agree with this, not only because it works in a clean and unambiguous way, but also because the Boss says so. This is clearly an Executive decision, and it is the kind of ruling that Bryce is the right guy to make. Easier than the Solomon/baby thing, but still, he must deal with a bunch of ignorant primadonnas like us. :-)
bob
On 10/9/2009 5:27 PM, Bryce Harrington wrote:
A compromise that retains but augments our current numbering scheme could be:
YEAR.SVG_COMPLIANCE.INCREMENTAL_NUMBER
So for example, we'd have:
2008.0.46 2009.0.47 2010.0.48 2010.0.49 ... 2010.1.00
Retains the same meaning and history of our current numbering scheme, plus makes the leftmost number more appealing to the wider userbase.
(I'm just throwing this idea out there, not advocating for it; I've no problems with our current numbering scheme, and am not really active enough in development these days to warrant having an opinion. But hey, unpainted bike shed!)
Bryce
On Oct 7, 2009, at 7:07 PM, Joshua A. Andler wrote:
On Wed, 2009-10-07 at 17:21 -0700, Joshua A. Andler wrote:
On Wed, 2009-10-07 at 19:36 -0400, Ted Gould wrote:
On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
That is, in a way the current <1.0 versioning quite misrepresents Inkscape and its features. Lately Hugin (which is a panorama making tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
+1 I hate version numbers. Anything to make them go away makes me happier.
+1 I just went to the Hugin page to see that it was how I thought. I really do like that scheme much better thank our current one.
Let me clarify, I'd say YEAR.INCREMENTING_NUMBER_STARTING_AT_ZERO
A year-based scheme is nice for marketing, but bad for programs.
One main point is that a major/minor scheme allows for compatibility. Given that we are moving more and more to have plugins do more and extending things, versioning is important.
We could have a separate API version and program version, but that would really confuse users.
On Fri, 2009-10-09 at 18:25 -0700, Jon A. Cruz wrote:
One main point is that a major/minor scheme allows for compatibility. Given that we are moving more and more to have plugins do more and extending things, versioning is important.
We could have a separate API version and program version, but that would really confuse users.
I really think a separate plugin API makes some amount of sense in that we probably wouldn't rev it every version. If we had only revision plugin authors would have to change their plugin to recognize the new release. I'm not sure that we can't make that understandable for users, at least as understandable and an enumerated list of versions.
--Ted
On Oct 10, 2009, at 6:25 AM, Ted Gould wrote:
I really think a separate plugin API makes some amount of sense in that we probably wouldn't rev it every version. If we had only revision plugin authors would have to change their plugin to recognize the new release. I'm not sure that we can't make that understandable for users, at least as understandable and an enumerated list of versions.
Ok. If you think that makes sense, then we can probably make it work. As long as things are explicit, it sounds good. In hand with the app version Bryce mentioned we can get a nice combo going.
Was a consensus reached on doing a new versioning scheme? I added 0.48, 0.49, etc. to launchpad for milestones, but can update them to whatever is decided. Let me know.
Bryce
On Thu, Oct 1, 2009 at 3:44 AM, Alexandre Prokoudine < alexandre.prokoudine@...400...> wrote:
Hi,
Don't know for you, but to me Inkscape seems to be inside the <1.0 loop forever, whereas people all around effectively use it for solving Real Life (C)(R)(tm) tasks. Yes, it is unbearably slow, it cannot work as a standalone prepress tool and so on and so forth. Nevertheless, it's real tool, not toy.
I quite agree with you, but personally I don't feel the same way about the version numbers. 0.47 looks good to me, whereas 4.7 doesn't look as good, and 47.0 doesn't look as good, and 2.3 doesn't look as good. 0.4.7 also doesn't look as good. 0.47 looks nice :-)
That is, in a way the current <1.0 versioning quite misrepresents
Inkscape and its features.
Not sure about that. To me, I don't care much. But 0.47 makes me think that there have been 47 releases (ignoring ones like 0.45.1)...
Lately Hugin (which is a panorama making
tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we probably discuss whether we need something like that?
I reckon that that's ugly. In my opinion you need to either go with "Inkscape 2010" and only have one release per year, or do it like Ubuntu does: "Inkscape 10.04" for a release next April. 2010.04, 2010.1, 2010-1.0, none of them look as good.
This would be another way to deal with the roadmap that we don't
really follow anyway.
The roadmap is a useful thing though, even if you just stick in an "Expected date of completion: July 2037"... currently I know that basic animation support is coming in 0.48. I mean 0.49. I mean 0.50. I mean 0.51...
/me ducks
Ditto
-- Chris Morgan <chris.morganiser@...400...>
I'm good at making two things: mistakes and enemies.
participants (12)
-
unknown＠example.com -
Alexandre Prokoudine -
Bob Jamison -
Bryce Harrington -
Chris Morgan -
Jasper van de Gronde -
Jon A. Cruz -
Joshua A. Andler -
Krzysztof Kosiński -
Niko Kiirala -
Ted Gould -
the Adib