I've seen documentation of roadmaps and releases refer to the version numbering as possibly up for consideration of revision:
"Evaluate changing the numbering scheme to a date-based one, or setting more realistic goals for major (1.0, 2.0) releases" http://wiki.inkscape.org/wiki/index.php/Roadmap
I can see the next major release after 0.48.x as a candidate for change as the "9'er" may lend itself toward a new scheme.
* 0.49.0 --> 0.90.0 (followed by 1.0, 1.1, 2.0...) * 0.49.0 --> Inkscape 9 (followed by Inkscape 9.1, 10.0...)
There have been a lot of excellent developments to be release in the next release, including C++, cairo, alignment/distribution along with new possible builds on win64-bit (Partha's help), and native Mac OS X (some almost-ready builds are out there). If these all reach maturity for the release the new builds are providing an increase audience and userbase. A changing version numbering scheme could reflect the developers' acknowledgement of this and demonstrate the activity of the software project.
Just IMHO,
--Jared
On Fri, 2013-10-18 at 23:59 +0000, Jared Meidal wrote:
There have been a lot of excellent developments to be release in the next release, including C++, cairo, alignment/distribution along with new possible builds on win64-bit (Partha's help), and native Mac OS X (some almost-ready builds are out there). If these all reach maturity for the release the new builds are providing an increase audience and userbase. A changing version numbering scheme could reflect the developers' acknowledgement of this and demonstrate the activity of the software project.
You make a persuasive argument. I like the idea of moving from 0.49 to 5.0 with the idea that a 0.49 release is likely to uncover lots of bugs from our massive list of changes.
But whatever we do, I also like having a defined list of what would certify us for such a big release PR type event.
Martin,
On Fri, Oct 18, 2013 at 11:59:19PM +0000, Jared Meidal wrote:
I've seen documentation of roadmaps and releases refer to the version numbering as possibly up for consideration of revision:
"Evaluate changing the numbering scheme to a date-based one, or setting more realistic goals for major (1.0, 2.0) releases" http://wiki.inkscape.org/wiki/index.php/Roadmap
I wrote that in as more a placeholder, way, way back when. At the time we had consensus that Inkscape wasn't mature enough in terms of features and stability to justify calling it 1.0. I wanted to keep that as a goal in the roadmap, and to tie it to something tangible. SVG 1.0 seemed like a logical place to put a pin in, but there wasn't a huge amount of thought put into it. It could easily have been "Switch to Cairo for rendering."
I can see the next major release after 0.48.x as a candidate for change as the "9'er" may lend itself toward a new scheme.
- 0.49.0 --> 0.90.0 (followed by 1.0, 1.1, 2.0...)
This sounds like a good approach. Might go to 0.91 just to avoid the usual confusion people have with our 0.x0 releases (i.e. people will call it version 0.9.
- 0.49.0 --> Inkscape 9 (followed by Inkscape 9.1, 10.0...)
Seems like tooo big of a jup.
We also discussed date based version numbers. At the time it was quite a fad and a lot of projects were adopting that. Seems less widely used now, except by projects that follow strict time-based release schedules, like distributions.
There have been a lot of excellent developments to be release in the next release, including C++, cairo, alignment/distribution along with new possible builds on win64-bit (Partha's help), and native Mac OS X (some almost-ready builds are out there). If these all reach maturity for the release the new builds are providing an increase audience and userbase. A changing version numbering scheme could reflect the developers' acknowledgement of this and demonstrate the activity of the software project.
Yep.
Bryce
Just IMHO,
--Jared
October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clk...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (3)
-
Bryce Harrington -
Jared Meidal -
Martin Owens