Hey all,
Almost two years later and there has been no consensus. It is being brought up again due to a brief discussion with JonCruz via IRC. So, does anyone want to change from the leading 0 scheme at this point? Jon mentioned potential of 4.9 as opposed to 0.49, or the year/month method as Ubuntu uses for example, if 0.49 is released in Aug/Sept it would be 11.08/11.09. Bryce had also suggested a year/current system hybrid a couple years ago when last discussed, such as 2011.0.49 (which I guess I'd rather see something like that go more like 11.49).
So... thoughts on if we should do this? My vote? Yes... we need to have a solid leading number because that matters (psychologically) to a number of users. Besides, with Google & Mozilla incrementing version numbers in their software so quickly, it makes me feel less like we need to hold to a very developer oriented version numbering scheme. (come on, Thunderbird even flat out gets to skip a major digit, so that lessens the blow if we did do decimal bump for a 4.9 or whatever else imho)
Cheers, Josh
On 10 June 2011 14:35, Josh Andler <scislac@...400...> wrote:
we need to have a solid leading number because that matters (psychologically) to a number of users
+1
More important than the number is the released cycle mode; is 'when its ready' better than a fixed cycle?
On Fri, Jun 10, 2011 at 10:41 AM, Dave Crossland <dave@...1555...> wrote:
On 10 June 2011 14:35, Josh Andler <scislac@...400...> wrote:
we need to have a solid leading number because that matters (psychologically) to a number of users
+1
More important than the number is the released cycle mode; is 'when its ready' better than a fixed cycle?
Fixed cycle works in some projects very well, but given Inkscape's track record, I have a hard time seeing us being able to change to do that. Then again, anything is possible.
Adobe just switched from an 18-month to 2 year cycle for their products. So to me there is less incentive to make each release as "awesome packed" as in the past. So, us moving to a 3-month alternating cycle could be doable and healthy. 3 month new release, 3 month bugfix (unless needs to be pushed sooner or more frequently than the 3 month), repeat.
It would be nice to push a major version number in each distro cycle and to have a safe bugfix only release for distros to backport mid-cycle. Just my .02
Cheers, Josh
I think it is important to have a recognizable version number. Even though I've been using Inkscape a lot, I can seldom remember the version number of Inkscape but I can remember which version of Debian / Ubuntu I've been using.
/Jesper
On 2011-06-10 19:35, Josh Andler wrote:
Hey all,
Almost two years later and there has been no consensus. It is being brought up again due to a brief discussion with JonCruz via IRC. So, does anyone want to change from the leading 0 scheme at this point? Jon mentioned potential of 4.9 as opposed to 0.49, or the year/month method as Ubuntu uses for example, if 0.49 is released in Aug/Sept it would be 11.08/11.09. Bryce had also suggested a year/current system hybrid a couple years ago when last discussed, such as 2011.0.49 (which I guess I'd rather see something like that go more like 11.49).
So... thoughts on if we should do this? My vote? Yes... we need to have a solid leading number because that matters (psychologically) to a number of users. Besides, with Google & Mozilla incrementing version numbers in their software so quickly, it makes me feel less like we need to hold to a very developer oriented version numbering scheme. (come on, Thunderbird even flat out gets to skip a major digit, so that lessens the blow if we did do decimal bump for a 4.9 or whatever else imho)
Cheers, Josh
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Jun 10, 2011 at 9:35 PM, Josh Andler wrote:
Bryce had also suggested a year/current system hybrid a couple years ago when last discussed, such as 2011.0.49
Please don't. YEAR.MONTH is really good enough.
Alexandre Prokoudine http://libregraphicsworld.org
Well, I'm viewing this from a linux distribution perspective. At the moment, whenever Ubuntu (or other widely-used distro) users upgrade to a new distribution version, they get a new upstream version of Firefox, OpenOffice/LibreOffice etc... this obviously attracts attention from development blogs/press-releases. However, Inkscape releases are less frequent than most linux distro-releases so users have to make do with a few patches that have been introduced by the package maintainer. I think that a fixed time release <= 6 months would ensure that we produce a new upstream release in time for most linux distribution releases. A version number >=1.0 would also give the impression of a >="usable" product, and I think we're certainly at that stage already.
AV
On 10 June 2011 21:52, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Fri, Jun 10, 2011 at 9:35 PM, Josh Andler wrote:
Bryce had also suggested a year/current system hybrid a couple years ago when last discussed, such as 2011.0.49
Please don't. YEAR.MONTH is really good enough.
Alexandre Prokoudine http://libregraphicsworld.org
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
I am not an active developer of Inkscape, nor a user of Linux but I use it for a while and I did some work on it. On the other side I have a long experience of building and promoting software in the cad business.
If you can't match deadlines, it is better to adapt deadlines until you can match them without too much stress. Moving from 0.47 to 0.49 implies to most users that you barely fixed a few bugs so it impacts credibility and IMO inkscape as is deserves a better deal.
I like the scheme used by SolidWorks (commercial but they started with a small team) : One release per year, named after the starting year. Say you ship in february 2011 it named Inkscape 2011
Followed by an index indicating the service pack, only bug fixes, I mean regressions, security, very minor enhancements. Instead of being a month it's a number. It can be reset each year (2011.00, 2011.01, 2011.02) or accumulated and in this case follow the .49, so it becomes 2011.49. Both seems excellent to me. For advanced users they will look for the number after the dot, most users will remember the year and go back to the site when they notice it is getting too old and they will remember the best vintage.
So a release cycle of one major per year and 3 patches (one per quarter) would be a mature choice. It implies to have 2 baselines one for next year release, one for current. 3 months before the release cycle a call to everyone to complete and commit new stuff, what is done is done, everything else is for next year. No stress.
Have a nice day, -Bruno
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
-----Original Message----- From: Alex Valavanis [mailto:valavanisalex@...400...] Sent: Saturday, June 11, 2011 1:45 AM To: Alexandre Prokoudine Cc: Inkscape Devel List Subject: Re: [Inkscape-devel] versioning scheme, take 2
Well, I'm viewing this from a linux distribution perspective. At the moment, whenever Ubuntu (or other widely-used distro) users upgrade to a new distribution version, they get a new upstream version of Firefox, OpenOffice/LibreOffice etc... this obviously attracts attention from development blogs/press-releases. However, Inkscape releases are less frequent than most linux distro-releases so users have to make do with a few patches that have been introduced by the package maintainer. I think that a fixed time release <= 6 months would ensure that we produce a new upstream release in time for most linux distribution releases. A version number >=1.0 would also give the impression of a >="usable" product, and I think we're certainly at that stage already.
AV
On 10 June 2011 21:52, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Fri, Jun 10, 2011 at 9:35 PM, Josh Andler wrote:
Bryce had also suggested a year/current system hybrid a couple years ago when last discussed, such as 2011.0.49
Please don't. YEAR.MONTH is really good enough.
Alexandre Prokoudine http://libregraphicsworld.org
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I vote for year.month.
2011.08 or 11.08 are both fine. Personally, I prefer '2011.08' style since the digits '2011' are suggesting 'This is the year number!' so clearly. -- Rationale:
year.month.... Like mentioned before, it makes users understand clearly what inkscape vintage they're using. Learn it once, and you're good to go recognizing Inkscape versions anywhere :)... from now on. This scheme also works nice with the current naming of the nightlies (year-month-day).
Incremental numbers like 0.49, 4.9, etc. do not seem appropriate, since they are a imitation of the older commercial software version numbering where it was necessary to 'pack' stuff in distinctly 'new' products, and where production cycle goes hand in hand with marketing and product's market lifecycle. OSS does not have those constraints.
Hybrid Confusing as hybrids tend to be. Neither time based nor version based. And, If I understand it correctly, can be somewhat redundantish since, if there is 2011.0.49, there could never be 2012.0.49. unless nothing is done for a whole year. Both orders have their own sequence, right?
On Sat, Jun 11, 2011 at 2:35 AM, Josh Andler <scislac@...400...> wrote:
Hey all,
Almost two years later and there has been no consensus. It is being brought up again due to a brief discussion with JonCruz via IRC. So, does anyone want to change from the leading 0 scheme at this point? Jon mentioned potential of 4.9 as opposed to 0.49, or the year/month method as Ubuntu uses for example, if 0.49 is released in Aug/Sept it would be 11.08/11.09. Bryce had also suggested a year/current system hybrid a couple years ago when last discussed, such as 2011.0.49 (which I guess I'd rather see something like that go more like 11.49).
So... thoughts on if we should do this? My vote? Yes... we need to have a solid leading number because that matters (psychologically) to a number of users. Besides, with Google & Mozilla incrementing version numbers in their software so quickly, it makes me feel less like we need to hold to a very developer oriented version numbering scheme. (come on, Thunderbird even flat out gets to skip a major digit, so that lessens the blow if we did do decimal bump for a 4.9 or whatever else imho)
Cheers, Josh
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2011-06-10 at 10:35 -0700, Josh Andler wrote:
Jon mentioned potential of 4.9
The version number is as much part of the brand as the name Inkscape and while it's fun for developers to have 0.49, what we're really calling it is 'Inkscape 49th attempt but not quite there'.
It's time to take the version number seriously, +1 to the proposed. Either 2.9 or 11 (per year) or 11.10 (more than one per year)
Of course we still don't support full SVG 1.1 spec, but then neither does anyone else.
Martin,
On Jun 11, 2011, at 4:31 PM, Martin Owens wrote:
On Fri, 2011-06-10 at 10:35 -0700, Josh Andler wrote:
Jon mentioned potential of 4.9
The version number is as much part of the brand as the name Inkscape and while it's fun for developers to have 0.49, what we're really calling it is 'Inkscape 49th attempt but not quite there'.
It's time to take the version number seriously, +1 to the proposed. Either 2.9 or 11 (per year) or 11.10 (more than one per year)
Of course we still don't support full SVG 1.1 spec, but then neither does anyone else.
So I think we're at a good decision point. First it seems clear that we do need to bump up the version and declare things ready for prime time.
Second, I think the year based scheme should be what we go with. A different numbering scheme could work, but if we move it forward then we lose the semantics of the major/minor compatibility issue that is so handy. On the other hand, a year based version clearly communicates to users when it was released, and how old it is getting.
Internally we can keep a compatibility version going, but externally we can focus on the 11.10 style. That also can help once we hit three or more releases per year.
On Fri, 2011-06-17 at 23:49 -0700, Jon Cruz wrote:
Second, I think the year based scheme should be what we go with. A different numbering scheme could work, but if we move it forward then we lose the semantics of the major/minor compatibility issue that is so handy. On the other hand, a year based version clearly communicates to users when it was released, and how old it is getting.
Internally we can keep a compatibility version going, but externally we can focus on the 11.10 style. That also can help once we hit three or more releases per year.
I second this. Year-based versioning (I think YEAR.MONTH specifically), with an internal semver-compliant version that keeps counting from 0.49 or whatever.
-mental
On Sat, Jun 18, 2011 at 1:00 AM, MenTaLguY <mental@...3...> wrote:
On Fri, 2011-06-17 at 23:49 -0700, Jon Cruz wrote:
Second, I think the year based scheme should be what we go with. A different numbering scheme could work, but if we move it forward then we lose the semantics of the major/minor compatibility issue that is so handy. On the other hand, a year based version clearly communicates to users when it was released, and how old it is getting.
Internally we can keep a compatibility version going, but externally we can focus on the 11.10 style. That also can help once we hit three or more releases per year.
I second this. Year-based versioning (I think YEAR.MONTH specifically), with an internal semver-compliant version that keeps counting from 0.49 or whatever.
I third this, seems like the way to go.
Cheers, Josh
Hi,
If you retain the year.month scheme I have the impression that keeping the year as 2011 as opposed to 11 is more self explanatory. Many users could just not realize that 11 is the year and stay using 11.03 until 2015. Sure it's longer.
About month. When will you apply the month number ? when you release ? so it means the release will be nameless until the very last moment and of course what about releasing 2012.01 when you are in december 2011. The benefit of service pack number is that 1 follows 0 whatever occurs.
Sincerely, -Bruno
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
On Tue, Jun 21, 2011 at 3:27 AM, Bruno Winck <bw@...2632...> wrote:
Hi,
If you retain the year.month scheme I have the impression that keeping the year as 2011 as opposed to 11 is more self explanatory. Many users could just not realize that 11 is the year and stay using 11.03 until 2015. Sure it's longer.
Honestly, if people need the full year in the version number, chances are they let all of their software get out of date and it won't matter to them anyway. If we were to have a sophisticated update system, sure we could be like Microsoft and do "Inkscape 2011" so we could do only one major update a year and they'd just get all the bug fixes quarterly or as needed. However, since we don't have that ability, with 2011.10, the .10 is then automatically ambiguous to that class of user. Something like 11.10 makes sense to those it matters to, and looks like a real version number of software to the common user.
About month. When will you apply the month number ? when you release ? so it means the release will be nameless until the very last moment and of course what about releasing 2012.01 when you are in december 2011. The benefit of service pack number is that 1 follows 0 whatever occurs.
Yes, month number will be month of release. Internally we are still using the old versioning scheme, so it isn't nameless. We're still working on 0.49 which will be 11.XX, then we will work on 0.50 which will be released as 12.X, an interim bugfix release which will use that month number as post decimal identification, then hopefully 0.51 will be 12.XX, etc.
Cheers, Josh
On Tue, Jun 21, 2011 at 9:14 PM, Felipe Sanches wrote:
Why don't we call it Inkscape 1.0 and move on?
Not until the SVG compliance is OK. We have a GSoC project for that, remember? :)
Not until performance is OK. We have a GSoC project for that as well, and we also rely on currently unstable version of Cairo.
Not until we fix a whole lot of bugs (transforms related ones are trending lately).
Alexandre Prokoudine http://libregraphicsworld.org
On 21-6-2011 19:04, Josh Andler wrote:
On Tue, Jun 21, 2011 at 3:27 AM, Bruno Winck<bw@...2632...> wrote:
Hi,
If you retain the year.month scheme I have the impression that keeping the year as 2011 as opposed to 11 is more self explanatory. Many users could just not realize that 11 is the year and stay using 11.03 until 2015. Sure it's longer.
Honestly, if people need the full year in the version number, chances are they let all of their software get out of date and it won't matter to them anyway. If we were to have a sophisticated update system, sure we could be like Microsoft and do "Inkscape 2011" so we could do only one major update a year and they'd just get all the bug fixes quarterly or as needed. However, since we don't have that ability, with 2011.10, the .10 is then automatically ambiguous to that class of user. Something like 11.10 makes sense to those it matters to, and looks like a real version number of software to the common user.
Since it is meant as the year number, what is the advantage of _not_ writing the year in full? I vote for full year number, what comes behind the dot might as well be a, b, c... ('2011a', '2011b', ...)
About month. When will you apply the month number ? when you release ? so it means the release will be nameless until the very last moment and of course what about releasing 2012.01 when you are in december 2011. The benefit of service pack number is that 1 follows 0 whatever occurs.
Yes, month number will be month of release. Internally we are still using the old versioning scheme, so it isn't nameless. We're still working on 0.49 which will be 11.XX, then we will work on 0.50 which will be released as 12.X, an interim bugfix release which will use that month number as post decimal identification, then hopefully 0.51 will be 12.XX, etc.
I think the month number is a valid concern, e.g. for about screen contests. Mentioning the month seems a bit too fine granularity for me (why not mention the day?). I think just numbering them 1, 2, 3, or a, b, c is nicer.
Ciao, Johan (trying to keep it simple)
On Tue, Jun 21, 2011 at 1:34 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 21-6-2011 19:04, Josh Andler wrote:
On Tue, Jun 21, 2011 at 3:27 AM, Bruno Winck<bw@...2632...> wrote:
Hi,
If you retain the year.month scheme I have the impression that keeping the year as 2011 as opposed to 11 is more self explanatory. Many users could just not realize that 11 is the year and stay using 11.03 until 2015. Sure it's longer.
Honestly, if people need the full year in the version number, chances are they let all of their software get out of date and it won't matter to them anyway. If we were to have a sophisticated update system, sure we could be like Microsoft and do "Inkscape 2011" so we could do only one major update a year and they'd just get all the bug fixes quarterly or as needed. However, since we don't have that ability, with 2011.10, the .10 is then automatically ambiguous to that class of user. Something like 11.10 makes sense to those it matters to, and looks like a real version number of software to the common user.
Since it is meant as the year number, what is the advantage of _not_ writing the year in full? I vote for full year number, what comes behind the dot might as well be a, b, c... ('2011a', '2011b', ...)
I wouldn't be opposed to this. I'd like to see others chime in though. In general though, the first two digits aren't necessary because it is highly unlikely that Inkscape will be around in 2111.
About month. When will you apply the month number ? when you release ? so it means the release will be nameless until the very last moment and of course what about releasing 2012.01 when you are in december 2011. The benefit of service pack number is that 1 follows 0 whatever occurs.
Yes, month number will be month of release. Internally we are still using the old versioning scheme, so it isn't nameless. We're still working on 0.49 which will be 11.XX, then we will work on 0.50 which will be released as 12.X, an interim bugfix release which will use that month number as post decimal identification, then hopefully 0.51 will be 12.XX, etc.
I think the month number is a valid concern, e.g. for about screen contests. Mentioning the month seems a bit too fine granularity for me (why not mention the day?). I think just numbering them 1, 2, 3, or a, b, c is nicer.
Well, given that Ubuntu's versioning scheme is 11.04 & 11.10 for this years releases, this is why you get down to month. If after this cycle we can actually get on regular release cycles matching the libraries we use as well as the distributions that carry us on the Linux side, it will be a big win for users (and for the community as a whole... no more guessing when releases will be).
At this point, as far as features go, a number as low as 1 is an insult to the maturity of the software in many areas (svg compliance aside). Are LPEs a version 1 feature? Heck no! Our awesome filter effect system (powerful, albeit complicated)? Nope. The jump to a number starting with 11 is a realistic ballpark number properly reflecting the maturity and capabilities Inkscape has. A very simple question is, which would an average individual think is more powerful, Illustrator 15 (CS5) or Inkscape 1?
Just my .02
Cheers, Josh
Hi,
Say you are December 23rd this year. 11.12 was done on December 1rst. The last bugfix of the year necessary due to some library bug. It can't be completed this day, everyone leaves until January 1rst. It is released January 2nd. Waiting behind the major release everyone has been working on. How do you name this bugfix ?
12.01 11.12 2011.8 (8th bug fix) 2011.h 11.13 11.12b
Last time someone suggest me shortening dates was back in 1985, to save 2 octets for each date. That was a trick a friend gave me, insider advice. So 1985 became 85, who could believe the program would survive the hardware. So hopes and virtuous release cycle are nice but IMO it is better to first reach such cycles and then enforce it in names. Otherwise it may fire back.
I hope to see Inkscape around on 2111 :)
-Bruno
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
-----Original Message----- From: Josh Andler [mailto:scislac@...400...] Sent: Tuesday, June 21, 2011 11:03 PM To: Johan Engelen Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] versioning scheme, take 2
On Tue, Jun 21, 2011 at 1:34 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 21-6-2011 19:04, Josh Andler wrote:
On Tue, Jun 21, 2011 at 3:27 AM, Bruno Winck<bw@...2632...> wrote:
Hi,
If you retain the year.month scheme I have the impression that keeping the year as 2011 as opposed to 11 is more self explanatory. Many users could just not realize that 11 is the year and stay using 11.03 until 2015. Sure it's longer.
Honestly, if people need the full year in the version number, chances are they let all of their software get out of date and it won't matter to them anyway. If we were to have a sophisticated update system, sure we could be like Microsoft and do "Inkscape 2011" so we could do only one major update a year and they'd just get all the bug fixes quarterly or as needed. However, since we don't have that ability, with 2011.10, the .10 is then automatically ambiguous to that class of user. Something like 11.10 makes sense to those it matters to, and looks like a real version number of software to the common user.
Since it is meant as the year number, what is the advantage of _not_ writing the year in full? I vote for full year number, what comes behind the dot might as well be a, b, c... ('2011a', '2011b', ...)
I wouldn't be opposed to this. I'd like to see others chime in though. In general though, the first two digits aren't necessary because it is highly unlikely that Inkscape will be around in 2111.
About month. When will you apply the month number ? when you release ? so it means the release will be nameless until the very last moment and of course what about releasing 2012.01 when you are in december 2011. The benefit of service pack number is that 1 follows 0 whatever occurs.
Yes, month number will be month of release. Internally we are still using the old versioning scheme, so it isn't nameless. We're still working on 0.49 which will be 11.XX, then we will work on 0.50 which will be released as 12.X, an interim bugfix release which will use that month number as post decimal identification, then hopefully 0.51 will be 12.XX, etc.
I think the month number is a valid concern, e.g. for about screen contests. Mentioning the month seems a bit too fine granularity for me (why not mention the day?). I think just numbering them 1, 2, 3, or a, b, c is nicer.
Well, given that Ubuntu's versioning scheme is 11.04 & 11.10 for this years releases, this is why you get down to month. If after this cycle we can actually get on regular release cycles matching the libraries we use as well as the distributions that carry us on the Linux side, it will be a big win for users (and for the community as a whole... no more guessing when releases will be).
At this point, as far as features go, a number as low as 1 is an insult to the maturity of the software in many areas (svg compliance aside). Are LPEs a version 1 feature? Heck no! Our awesome filter effect system (powerful, albeit complicated)? Nope. The jump to a number starting with 11 is a realistic ballpark number properly reflecting the maturity and capabilities Inkscape has. A very simple question is, which would an average individual think is more powerful, Illustrator 15 (CS5) or Inkscape 1?
Just my .02
Cheers, Josh
------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Jun 21, 2011 at 2:55 PM, Bruno Winck <bw@...2632...> wrote:
Say you are December 23rd this year. 11.12 was done on December 1rst. The last bugfix of the year necessary due to some library bug. It can't be completed this day, everyone leaves until January 1rst. It is released January 2nd. Waiting behind the major release everyone has been working on. How do you name this bugfix ?
12.01 11.12 2011.8 (8th bug fix) 2011.h 11.13 11.12b
12.01
Last time someone suggest me shortening dates was back in 1985, to save 2 octets for each date. That was a trick a friend gave me, insider advice. So 1985 became 85, who could believe the program would survive the hardware. So hopes and virtuous release cycle are nice but IMO it is better to first reach such cycles and then enforce it in names. Otherwise it may fire back.
There's nothing to backfire. The reality is that it won't be enforcing release cycles by name. Given that I've been the only steady release warden for the past few years *shudder*, I'm cracking down on our release policy. I need to put together a proposed release schedule. But the loose version is as such...
*Here in about a few days I set forth the dates for this schedule... *We release in hopefully October or November (we have a lot of changes this cycle to be watched and tested). *Just after release, I set forth the next schedule, which includes a bug-fix release to the stable branch 3 months out (planned, not to say we won't push one earlier). The synchronization of releases will most likely be planned so that our bugfix releases are the ones that get picked up by distros (this needs to be discussed). *Repeat the cycle (minus my current guesstimate) once the next "new" release makes it out.
Basically, we'll just change policy to "if a new feature is not ready enough, wait out a release cycle as it will be 6-months to tighten up that feature". This is a needed change as we seem to get people starting work in trunk and not finishing it, this is very bad practice.
This may mean we may end up with a 3rd branch for experimental features (where devs want things tested as they're writing), or that aren't otherwise in good enough shape for trunk. So, it may end up looking like "stable", "trunk", & "experimental" to still achieve continuous development. Note, a bonus to us doing this would have gotten the cairo stuff merged into "experimental" much earlier for more testing. This all needs to be discussed and a group consensus of the most active developers & testers is needed before any such changes would be made.
I guess the issue is that Inkscape is a pretty mature project now and we need to do some things to prevent repeating mistakes of the past... release frequency and development habits being two of those trouble areas.
I hope to see Inkscape around on 2111 :)
I won't likely be alive in 2111. ;) Besides, if Inkscape is around in 2111 in some form, I think it will just be called Inkscape and whatever computers will just magically keep it all up to date for you... and draw what you see in your head for you as well. ;)
Cheers, Josh
2011/6/22 Josh Andler <scislac@...400...>:
This may mean we may end up with a 3rd branch for experimental features (where devs want things tested as they're writing), or that aren't otherwise in good enough shape for trunk. So, it may end up looking like "stable", "trunk", & "experimental" to still achieve continuous development.
I don't think this is a good idea. As soon as several features are merged in experimental, all in various states of "readiness", the experimental will transform into the trunk, trunk will become quasi-stable, and stable will become "nobody works on this any more". Merging a specific feature from experimental would be tedious (you have to find all commits related to it).
Regards, Krzysztof
2011/6/21 Krzysztof Kosiński <tweenk.pl@...400...>:
2011/6/22 Josh Andler <scislac@...400...>:
This may mean we may end up with a 3rd branch for experimental features (where devs want things tested as they're writing), or that aren't otherwise in good enough shape for trunk. So, it may end up looking like "stable", "trunk", & "experimental" to still achieve continuous development.
I don't think this is a good idea. As soon as several features are merged in experimental, all in various states of "readiness", the experimental will transform into the trunk, trunk will become quasi-stable, and stable will become "nobody works on this any more". Merging a specific feature from experimental would be tedious (you have to find all commits related to it).
This is definitely a fear of mine and why I wanted people to discuss it. So, just change the rule from "don't break trunk" to "don't commit until a feature is pretty much done and in need of wider testing so it can get polish"? It includes the original rule and prevents the pieces of a feature stuff we've suffered from. Basically, it will just impose better practices on our contributors. Any other suggestions or thoughts?
Cheers, Josh
On Jun 22, 2011, at 7:48, Josh Andler <scislac@...400...> wrote:
if Inkscape is around in 2111 in some form, I think it will just be called Inkscape.
Just Inkscape is the goal then! :) but seriously, youre right, inkscape is the key thing! version is an important but secondary information.
There's no box where inkscape's version number must be stuck in big letters in its glory to sell more. Inkscape is not a part of proprietary software marketing mess, and I we should stop thinking about the version number as an element of branding and guide our thinking towards it's purpose, what it means, and how this info should get to users and contributors.
We need vintage, let's use a timecode that's been mostly stable for a couple of centuries or so. ;) YYYY-MM-DD (i believe that this numbering can even be simply and exactly translated into any calendar writing style on this planet, depending on the culture). It is a human timecode! linear, lean and simple and, if there's a need for finer divisions, those are ready, too. hh-mm-ss. ;)
Then, it seems we need an indication of 'stability'. And, from what is visible in the duscussion there are 3 main 'states' of inkscape to be marked. How about colors? Red, yellow and green. Colors seem to be tested and stable since, well... Easily translatable. You can paint it, you can write it's name... and these three are globally recognizable too. Green - go! It's fine and safe! Yellow - you can try but it's better to wait a bit with this one. Red - stop, this is not for you. ..its for those who know ;)
- hey, Omar, which inkscape should i use?' - Hi, just get the last month's green. Green is good, remember? - a'righ..
Instead of:
- hey Omar, which inkscape should i use? - lets see.. Was it 12.03a? Wait a sec.... Hm now they have 12.03b... Oh and 12.04c. Ack. Errr, listen, try 12.03b and let me know if it works... But it should work fine. - if it works? Omar...
Alex
On Tue, Jun 21, 2011 at 7:08 PM, Aleksandar Kovac <alex.open.design@...400...> wrote:
On Jun 22, 2011, at 7:48, Josh Andler <scislac@...400...> wrote:
if Inkscape is around in 2111 in some form, I think it will just be called Inkscape.
Just Inkscape is the goal then! :) but seriously, youre right, inkscape is the key thing! version is an important but secondary information.
Just Inkscape is indeed the goal! Version numbers are very secondary to the dev community. Unfortunately they're much more important to the average user. If cost is of no issue, do I want a 1995 Honda Civic or a 2011 BMW Whatever? I'd go with the 2011 hands down. 1995 BMW Whatever vs 2011 Honda Civic, again... 2011 wins.
There's no box where inkscape's version number must be stuck in big letters in its glory to sell more. Inkscape is not a part of proprietary software marketing mess, and I we should stop thinking about the version number as an element of branding and guide our thinking towards it's purpose, what it means, and how this info should get to users and contributors.
We really are part of the proprietary software marketing mess mentality. Is it our issue? Only as much as other software makes it so. With Chrome & Firefox switching to rapid release cycles, IE will start to be viewed as "immature" by new users (number-wise). Features are secondary to the formula of "how long have you been making this product and what version are you on?"
For Inkscape it is important branding-wise to establish that the software is mature and we've had a lot of releases and progress since the project began. I guess the problem really is we're not looking to get sales, we're looking to offer really solid alternatives to the industry standard tools, which can empower users, with the bonus of it being at no cost.
We need vintage, let's use a timecode that's been mostly stable for a couple of centuries or so. ;) YYYY-MM-DD (i believe that this numbering can even be simply and exactly translated into any calendar writing style on this planet, depending on the culture). It is a human timecode! linear, lean and simple and, if there's a need for finer divisions, those are ready, too. hh-mm-ss. ;)
Then, it seems we need an indication of 'stability'. And, from what is visible in the duscussion there are 3 main 'states' of inkscape to be marked. How about colors? Red, yellow and green. Colors seem to be tested and stable since, well... Easily translatable. You can paint it, you can write it's name... and these three are globally recognizable too. Green - go! It's fine and safe! Yellow - you can try but it's better to wait a bit with this one. Red - stop, this is not for you. ..its for those who know ;)
Let's say I thought you were being serious in any way... The discussion of handling branches in no way affects users downloads. There is never anything for the average user but "here's the current supported and recommended version". That's it. What happens on the development/testing side of things vs the end-user releases is completely different.
Cheers, Josh
I have worked on SVG Filters and SVG Fonts because I was willing to see Inkscape reach 1.0! Because I knew 1.0 meant full SVG compliance. If we are concerned about 0.49 psicologically conveying a different meaning to the users, something like "49th release but not there yet!", then maybe we should reconsider what 1.0 means. Several years with 0.something++ releases creates a strong expectation of "when is 1.0 gonna be reached?!". So, if we reinterpret 1.0 as meaning "ready for professional usage", then maybe we are closer to reaching that, and maybe our next release can be "Inkscape 1.0". Or maybe it can still be Inkscape 0.49 and then keep "Inkscape 1.0" for one of the next ones in the future. At least that way we both stop sending the wrong message ("Inkscape is not ready") and give a positive message to users: "Inkscape 1.0 is there! It is ready!"
Simply changing the versioning scheme to something "neutral" like "Inkscape 2011.October" does not send that positive, encouragement message to our potential new users.
So I suggest we change the focus of the discussion to a debate on the following question: *Ignoring the previous SVG compliance criteria, what does Inkscape still need feature-wise to be ready for professional graphic design work so that we can finally release it as Inkscape 1.0 ? * Felipe Sanches
On Tue, Jun 21, 2011 at 10:14 PM, Felipe Sanches <juca@...2270...> wrote:
So I suggest we change the focus of the discussion to a debate on the following question: Ignoring the previous SVG compliance criteria, what does Inkscape still need feature-wise to be ready for professional graphic design work so that we can finally release it as Inkscape 1.0 ?
Inkscape 1.0 is insulting to you, and all of our other dedicated developers. We're keeping the version numbering as intended for internal/development use. All I have to say is... PLEASE TAKE PRIDE in the awesomeness of your contributions and those of others. We are NOT a 1.0 product as far as users are concerned. Felipe, I praise you left and right and would never say even your contributions alone are only 1.0 worthy. We're >10.0+ quality. Don't sell yourself or Inkscape short.
Again, just imho.
Cheers, Josh
heh! thanks for the good things you said! I appreciate your work in the team also :-)
But I still think it is silly to be called 2.0 (or whatever "n dot zero" for n>1) without having ever released 1.0 :-P And I dont want to miss the opportunity to convey the "we are professional quality libre-software" message by simply adopting a neutral year.month versioning scheme.
Felipe
On Wed, Jun 22, 2011 at 3:23 AM, Josh Andler <scislac@...400...> wrote:
On Tue, Jun 21, 2011 at 10:14 PM, Felipe Sanches <juca@...2270...> wrote:
So I suggest we change the focus of the discussion to a debate on the following question: Ignoring the previous SVG compliance criteria, what does Inkscape still
need
feature-wise to be ready for professional graphic design work so that we
can
finally release it as Inkscape 1.0 ?
Inkscape 1.0 is insulting to you, and all of our other dedicated developers. We're keeping the version numbering as intended for internal/development use. All I have to say is... PLEASE TAKE PRIDE in the awesomeness of your contributions and those of others. We are NOT a 1.0 product as far as users are concerned. Felipe, I praise you left and right and would never say even your contributions alone are only 1.0 worthy. We're >10.0+ quality. Don't sell yourself or Inkscape short.
Again, just imho.
Cheers, Josh
Oh! And I remember Firefox 0.9.3 was already pretty good software!
On Wed, Jun 22, 2011 at 3:36 AM, Felipe Sanches <juca@...2270...>wrote:
heh! thanks for the good things you said! I appreciate your work in the team also :-)
But I still think it is silly to be called 2.0 (or whatever "n dot zero" for n>1) without having ever released 1.0 :-P And I dont want to miss the opportunity to convey the "we are professional quality libre-software" message by simply adopting a neutral year.month versioning scheme.
Felipe
On Wed, Jun 22, 2011 at 3:23 AM, Josh Andler <scislac@...400...> wrote:
On Tue, Jun 21, 2011 at 10:14 PM, Felipe Sanches <juca@...2270...> wrote:
So I suggest we change the focus of the discussion to a debate on the following question: Ignoring the previous SVG compliance criteria, what does Inkscape still
need
feature-wise to be ready for professional graphic design work so that we
can
finally release it as Inkscape 1.0 ?
Inkscape 1.0 is insulting to you, and all of our other dedicated developers. We're keeping the version numbering as intended for internal/development use. All I have to say is... PLEASE TAKE PRIDE in the awesomeness of your contributions and those of others. We are NOT a 1.0 product as far as users are concerned. Felipe, I praise you left and right and would never say even your contributions alone are only 1.0 worthy. We're >10.0+ quality. Don't sell yourself or Inkscape short.
Again, just imho.
Cheers, Josh
Can we have an Inkscape 1.0 full page ad in the New York Times ? :-D (just joking...)
On Wed, Jun 22, 2011 at 3:39 AM, Felipe Sanches <juca@...2270...>wrote:
Oh! And I remember Firefox 0.9.3 was already pretty good software!
On Wed, Jun 22, 2011 at 3:36 AM, Felipe Sanches <juca@...2270...>wrote:
heh! thanks for the good things you said! I appreciate your work in the team also :-)
But I still think it is silly to be called 2.0 (or whatever "n dot zero" for n>1) without having ever released 1.0 :-P And I dont want to miss the opportunity to convey the "we are professional quality libre-software" message by simply adopting a neutral year.month versioning scheme.
Felipe
On Wed, Jun 22, 2011 at 3:23 AM, Josh Andler <scislac@...400...> wrote:
On Tue, Jun 21, 2011 at 10:14 PM, Felipe Sanches <juca@...2270...> wrote:
So I suggest we change the focus of the discussion to a debate on the following question: Ignoring the previous SVG compliance criteria, what does Inkscape still
need
feature-wise to be ready for professional graphic design work so that
we can
finally release it as Inkscape 1.0 ?
Inkscape 1.0 is insulting to you, and all of our other dedicated developers. We're keeping the version numbering as intended for internal/development use. All I have to say is... PLEASE TAKE PRIDE in the awesomeness of your contributions and those of others. We are NOT a 1.0 product as far as users are concerned. Felipe, I praise you left and right and would never say even your contributions alone are only 1.0 worthy. We're >10.0+ quality. Don't sell yourself or Inkscape short.
Again, just imho.
Cheers, Josh
If Mozilla wants to fund it... ;)
On Tue, Jun 21, 2011 at 11:40 PM, Felipe Sanches <juca@...2270...> wrote:
Can we have an Inkscape 1.0 full page ad in the New York Times ? :-D (just joking...)
On Wed, Jun 22, 2011 at 3:39 AM, Felipe Sanches <juca@...2270...> wrote:
Oh! And I remember Firefox 0.9.3 was already pretty good software!
On Wed, Jun 22, 2011 at 3:36 AM, Felipe Sanches <juca@...2270...> wrote:
heh! thanks for the good things you said! I appreciate your work in the team also :-)
But I still think it is silly to be called 2.0 (or whatever "n dot zero" for n>1) without having ever released 1.0 :-P And I dont want to miss the opportunity to convey the "we are professional quality libre-software" message by simply adopting a neutral year.month versioning scheme.
Felipe
On Wed, Jun 22, 2011 at 3:23 AM, Josh Andler <scislac@...400...> wrote:
On Tue, Jun 21, 2011 at 10:14 PM, Felipe Sanches <juca@...2270...> wrote:
So I suggest we change the focus of the discussion to a debate on the following question: Ignoring the previous SVG compliance criteria, what does Inkscape still need feature-wise to be ready for professional graphic design work so that we can finally release it as Inkscape 1.0 ?
Inkscape 1.0 is insulting to you, and all of our other dedicated developers. We're keeping the version numbering as intended for internal/development use. All I have to say is... PLEASE TAKE PRIDE in the awesomeness of your contributions and those of others. We are NOT a 1.0 product as far as users are concerned. Felipe, I praise you left and right and would never say even your contributions alone are only 1.0 worthy. We're >10.0+ quality. Don't sell yourself or Inkscape short.
Again, just imho.
Cheers, Josh
participants (13)
-
Aleksandar Kovac -
Alex Valavanis -
Alexandre Prokoudine -
Bruno Winck -
Dave Crossland -
Felipe Sanches -
Jesper Öqvist -
Johan Engelen -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
MenTaLguY