Re: [Inkscape-devel] Version number
My vote is for Inkscape 5, pointing to maturity of the .4x.x line, and to demonstrate overall reliability and maturity of the application.
My secondary vote, would be for Inkscape 0.91, moving toward a 1.0 release.
Overall it would be great to update a features-to-version-number page to help map where we are, and where going.
--Jared
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
How about this:
1. We rename Inkscape 0.49 to Inkscape 0.91 2. In the next cycle, we actively work to address the two major bugs (flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
Regards, Krzysztof
That sounds like a solid compromise imho... especially if the cycle is dedicated to those two things and bug fixes (NO NEW FEATURES). As it would be possible to get a release out relatively fast if those were purely the focus. I'm pretty sure people who have problems with either of those would say they're "special release" worthy.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:15 AM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
How about this:
- We rename Inkscape 0.49 to Inkscape 0.91
- In the next cycle, we actively work to address the two major bugs
(flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
Regards, Krzysztof
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
That sounds like a great plan to me, although I'd also like to see a robust testing infrastructure and full Gtk+ 3.x support in Inkscape 1.0. Shipping a 1.0 release with an "experimental" build option is asking for trouble!
AV
On 24 October 2013 14:34, Josh Andler <scislac@...400...> wrote:
That sounds like a solid compromise imho... especially if the cycle is dedicated to those two things and bug fixes (NO NEW FEATURES). As it would be possible to get a release out relatively fast if those were purely the focus. I'm pretty sure people who have problems with either of those would say they're "special release" worthy.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:15 AM, Krzysztof Kosiński <tweenk.pl@...847...0...> wrote:
How about this:
- We rename Inkscape 0.49 to Inkscape 0.91
- In the next cycle, we actively work to address the two major bugs
(flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
Regards, Krzysztof
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Last I heard from JonCruz (sometime within the past week I think) he was going to start hooking up the Google test stuff, and he said it could take some time. As for the GTK3 support, I want to see it, but it will take a SERIOUS UX evaluation... inkscape in gtk2 is scary at the most common resolution available today, when I've done gtk3 test builds here all I say is WTF to all the touch chrome. :-/
Not trying to invalidate your desire with gtk3 (I'm a big fan of moving to newer libraries in almost any case), I just fear for lower-res non-touch devices.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:37 AM, Alex Valavanis <valavanisalex@...400...> wrote:
That sounds like a great plan to me, although I'd also like to see a robust testing infrastructure and full Gtk+ 3.x support in Inkscape 1.0. Shipping a 1.0 release with an "experimental" build option is asking for trouble!
AV
On 24 October 2013 14:34, Josh Andler <scislac@...400...> wrote:
That sounds like a solid compromise imho... especially if the cycle is dedicated to those two things and bug fixes (NO NEW FEATURES). As it would be possible to get a release out relatively fast if those were purely the focus. I'm pretty sure people who have problems with either of those would say they're "special release" worthy.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:15 AM, Krzysztof Kosiński <tweenk.pl@...1857...00...> wrote:
How about this:
- We rename Inkscape 0.49 to Inkscape 0.91
- In the next cycle, we actively work to address the two major bugs
(flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
Regards, Krzysztof
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
@Guillermo - Version numbers aren't decimals. The period separates major & minor release identifiers. i.e., "0.9" is "major = 0, minor = 9", so it is lower than the current "major = 0, minor = 48" releases. 0.91 was suggested instead of 0.90 to avoid this possible confusion.
@Josh - Yes, it would be great to hook up the Google test stuff eventually, but I'd be happy with just fixing the last couple of issues with the cxxtest suite for the time being. Maybe "robust" was the wrong word! Similarly, I think it should be fairly straightforward to add the rendering tests into "make check". As such, this would make v1.0 a usable benchmark release for limited automated regression testing of some aspects of the code.
As for the GTK+ 3 stuff, yeah, I agree that it'll take a lot of testing before we endorse user-builds so we can put it on hold. However, we should probably aim to fix up the known bugs http://goo.gl/06WnfD. I just don't feel very confident about stamping "This is a stable release" on something that has such a crappy build option available, even if it is marked as an experimental feature.
AV
On 24 October 2013 14:46, Josh Andler <scislac@...400...> wrote:
Last I heard from JonCruz (sometime within the past week I think) he was going to start hooking up the Google test stuff, and he said it could take some time. As for the GTK3 support, I want to see it, but it will take a SERIOUS UX evaluation... inkscape in gtk2 is scary at the most common resolution available today, when I've done gtk3 test builds here all I say is WTF to all the touch chrome. :-/
Not trying to invalidate your desire with gtk3 (I'm a big fan of moving to newer libraries in almost any case), I just fear for lower-res non-touch devices.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:37 AM, Alex Valavanis <valavanisalex@...400...> wrote:
That sounds like a great plan to me, although I'd also like to see a robust testing infrastructure and full Gtk+ 3.x support in Inkscape 1.0. Shipping a 1.0 release with an "experimental" build option is asking for trouble!
AV
On 24 October 2013 14:34, Josh Andler <scislac@...400...> wrote:
That sounds like a solid compromise imho... especially if the cycle is dedicated to those two things and bug fixes (NO NEW FEATURES). As it would be possible to get a release out relatively fast if those were purely the focus. I'm pretty sure people who have problems with either of those would say they're "special release" worthy.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:15 AM, Krzysztof Kosiński <tweenk.pl@...360...400...> wrote:
How about this:
- We rename Inkscape 0.49 to Inkscape 0.91
- In the next cycle, we actively work to address the two major bugs
(flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
Regards, Krzysztof
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2013-10-24 at 15:22 +0100, Alex Valavanis wrote:
@Josh - Yes, it would be great to hook up the Google test stuff eventually, but I'd be happy with just fixing the last couple of issues with the cxxtest suite for the time being. Maybe "robust" was the wrong word! Similarly, I think it should be fairly straightforward to add the rendering tests into "make check". As such, this would make v1.0 a usable benchmark release for limited automated regression testing of some aspects of the code.
As for the GTK+ 3 stuff, yeah, I agree that it'll take a lot of testing before we endorse user-builds so we can put it on hold. However, we should probably aim to fix up the known bugs http://goo.gl/06WnfD. I just don't feel very confident about stamping "This is a stable release" on something that has such a crappy build option available, even if it is marked as an experimental feature.
Sounds like you have two more reasonable bug or blueprint proposals to attach to the 1.0 milestone.
Please keep the 1.0 release process tidy by including these in the project system.
Best Regards, Martin Owens
El 24/10/13 11:22, Alex Valavanis escribió:
@Guillermo - Version numbers aren't decimals. The period separates major & minor release identifiers. i.e., "0.9" is "major = 0, minor = 9", so it is lower than the current "major = 0, minor = 48" releases. 0.91 was suggested instead of 0.90 to avoid this possible confusion.
I understand, but notice how users (like me, for instance) read it :-)
For regular people used to decimals, 0.5 is halfway to 1, and 0.5 is more than 0.48.
Anyway, I get it and what Krzysztof pointed out about package managers makes my entire point moot.
Just wanted to comment about a potential communication issue with users. From this side, jumping from 0.49 to 0.91 is... wtf :.p
Gez.
What about just 0.50, if 0.5 doesn't work? We would come to that anyway soon enough.
On Thu, Oct 24, 2013 at 11:56 AM, Guillermo Espertino (Gez) <gespertino@...400...> wrote:
El 24/10/13 11:22, Alex Valavanis escribió:
@Guillermo - Version numbers aren't decimals. The period separates major & minor release identifiers. i.e., "0.9" is "major = 0, minor = 9", so it is lower than the current "major = 0, minor = 48" releases. 0.91 was suggested instead of 0.90 to avoid this possible confusion.
I understand, but notice how users (like me, for instance) read it :-)
For regular people used to decimals, 0.5 is halfway to 1, and 0.5 is more than 0.48.
Anyway, I get it and what Krzysztof pointed out about package managers makes my entire point moot.
Just wanted to comment about a potential communication issue with users. From this side, jumping from 0.49 to 0.91 is... wtf :.p
Gez.
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, Oct 24, 2013 at 12:13:17PM -0300, Dmitry Kirsanov wrote:
What about just 0.50, if 0.5 doesn't work? We would come to that anyway soon enough.
Well, remember what happened when we did 0.30 and 0.40; users shortened it to 0.3 and 0.4, which was annoying to us and led to some confusion. I recall even some printed articles made the mistake.
I like 0.50 as a nice round number, but if we're going to jump version numbers anyway, why jump to a version number that's going to incur an extra degree of confusion in addition to the jump itself, if we can avoid it up front?
Version 0.9 sounds like a release from a project that just recently got started, and hasn't really been exposed to much user testing. 0.91 sounds like something from a serious project that's been around a few years. :-)
Bryce
On Thu, Oct 24, 2013 at 11:56 AM, Guillermo Espertino (Gez) <gespertino@...400...> wrote:
El 24/10/13 11:22, Alex Valavanis escribió:
@Guillermo - Version numbers aren't decimals. The period separates major & minor release identifiers. i.e., "0.9" is "major = 0, minor = 9", so it is lower than the current "major = 0, minor = 48" releases. 0.91 was suggested instead of 0.90 to avoid this possible confusion.
I understand, but notice how users (like me, for instance) read it :-)
For regular people used to decimals, 0.5 is halfway to 1, and 0.5 is more than 0.48.
Anyway, I get it and what Krzysztof pointed out about package managers makes my entire point moot.
Just wanted to comment about a potential communication issue with users. From this side, jumping from 0.49 to 0.91 is... wtf :.p
Gez.
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2013-10-25 at 12:00 -0700, Bryce Harrington wrote:
0.91 sounds like something from a serious project that's been around a few years. :-)
Hmm according to my chart, 0.9.1 is a beta and >0.11 is a serious project that's scared of it's own release ;-)
Martin,
Hi, What about dropping the zero before 0.49. Inkscape v49 looks more trustable than 0.49. We don't talk about 1.0 anymore, and the same version numbers granularity is kept.
Steren
On Fri, Oct 25, 2013 at 10:48 PM, Martin Owens <doctormo@...400...> wrote:
On Fri, 2013-10-25 at 12:00 -0700, Bryce Harrington wrote:
0.91 sounds like something from a serious project that's been around a few years. :-)
Hmm according to my chart, 0.9.1 is a beta and >0.11 is a serious project that's scared of it's own release ;-)
Martin,
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Right... I finally got round to making a meta-report for the cxxtest issues [1]. I've provisionally targeted it to the 0.49 release because I'm pretty certain that the issues are very easy to fix for people who are familiar with those sections of the code. If someone can explain why any of the issues are too difficult to fix, we can always push this back to the 1.0 release, but I'd prefer to have automated testing in place as soon as possible.
Thanks,
AV
[1] https://bugs.launchpad.net/inkscape/+bug/1249324
On 25 October 2013 22:23, Steren <steren.giannini@...400...> wrote:
Hi, What about dropping the zero before 0.49. Inkscape v49 looks more trustable than 0.49. We don't talk about 1.0 anymore, and the same version numbers granularity is kept.
Steren
On Fri, Oct 25, 2013 at 10:48 PM, Martin Owens <doctormo@...400...> wrote:
On Fri, 2013-10-25 at 12:00 -0700, Bryce Harrington wrote:
0.91 sounds like something from a serious project that's been around a few years. :-)
Hmm according to my chart, 0.9.1 is a beta and >0.11 is a serious project that's scared of it's own release ;-)
Martin,
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, Oct 24, 2013 at 03:22:49PM +0100, Alex Valavanis wrote:
@Josh - Yes, it would be great to hook up the Google test stuff eventually, but I'd be happy with just fixing the last couple of issues with the cxxtest suite for the time being. Maybe "robust" was the wrong word! Similarly, I think it should be fairly straightforward to add the rendering tests into "make check". As such, this would make v1.0 a usable benchmark release for limited automated regression testing of some aspects of the code.
I agree; improving the existing test suite is low risk high reward, whereas rewriting the test suite should be considered a new feature.
Also, I should suggest that rewriting the test suite may be inadvisable; getting people to write tests is hard enough without the framework becoming a moving target. :-)
I know from experience that writing tests can be tedious, and redoing the framework can be quite tempting. But the value of a test framework is only as good as the tests it runs, so investment in better tests always pays off more than investment in framework development.
As for the GTK+ 3 stuff, yeah, I agree that it'll take a lot of testing before we endorse user-builds so we can put it on hold. However, we should probably aim to fix up the known bugs http://goo.gl/06WnfD. I just don't feel very confident about stamping "This is a stable release" on something that has such a crappy build option available, even if it is marked as an experimental feature.
Could always just disable showing that build option for the release branch, but leave it available in the master branch. Especially if it's there only for the benefit of developers right now.
AV
On 24 October 2013 14:46, Josh Andler <scislac@...400...> wrote:
Last I heard from JonCruz (sometime within the past week I think) he was going to start hooking up the Google test stuff, and he said it could take some time. As for the GTK3 support, I want to see it, but it will take a SERIOUS UX evaluation... inkscape in gtk2 is scary at the most common resolution available today, when I've done gtk3 test builds here all I say is WTF to all the touch chrome. :-/
Not trying to invalidate your desire with gtk3 (I'm a big fan of moving to newer libraries in almost any case), I just fear for lower-res non-touch devices.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:37 AM, Alex Valavanis <valavanisalex@...1063....> wrote:
That sounds like a great plan to me, although I'd also like to see a robust testing infrastructure and full Gtk+ 3.x support in Inkscape 1.0. Shipping a 1.0 release with an "experimental" build option is asking for trouble!
AV
On 24 October 2013 14:34, Josh Andler <scislac@...400...> wrote:
That sounds like a solid compromise imho... especially if the cycle is dedicated to those two things and bug fixes (NO NEW FEATURES). As it would be possible to get a release out relatively fast if those were purely the focus. I'm pretty sure people who have problems with either of those would say they're "special release" worthy.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:15 AM, Krzysztof Kosiński <tweenk.pl@...233.....400...> wrote:
How about this:
- We rename Inkscape 0.49 to Inkscape 0.91
- In the next cycle, we actively work to address the two major bugs
(flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
Regards, Krzysztof
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
The version 0.91 toward 1.0 release sounds great to me. I like the idea of the 1.0 release dealing with a small target of focused features added, plus any 0.9x bugs. Flowtext and coordinates are features I certainty would make use of, I think it would keep me within Inkscape more often than jumping over to Scribus at times in project creation.
--Jared
Alex Valavanis <valavanisalex@...400...> wrote:
That sounds like a great plan to me, although I'd also like to see a robust testing infrastructure and full Gtk+ 3.x support in Inkscape 1.0. Shipping a 1.0 release with an "experimental" build option is asking for trouble!
AV
On 24 October 2013 14:34, Josh Andler <scislac@...400...> wrote:
That sounds like a solid compromise imho... especially if the cycle is dedicated to those two things and bug fixes (NO NEW FEATURES). As it would be possible to get a release out relatively fast if those were purely the focus. I'm pretty sure people who have problems with either of those would say they're "special release" worthy.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:15 AM, Krzysztof Kosiński <tweenk.pl@...1063....> wrote:
How about this:
- We rename Inkscape 0.49 to Inkscape 0.91
- In the next cycle, we actively work to address the two major bugs
(flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
Regards, Krzysztof
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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=60135991&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
A bit of an aside: doing a web search for 'inkscape 1.0' turns up some relevant stuff (eg milestones), while a search for 'inkscape 5.0' turns up a lot up ambush-ware (eg CNET, softpedia).
Probably not a huge deal, but I was messing around with search terms and thought I'd share ;)
Chris
2013/10/24 Josh Andler <scislac@...400...>:
That sounds like a solid compromise imho... especially if the cycle is dedicated to those two things and bug fixes (NO NEW FEATURES). As it would be possible to get a release out relatively fast if those were purely the focus. I'm pretty sure people who have problems with either of those would say they're "special release" worthy.
The cycle doesn't have to be limited to those two features; some other work could also go in if it's completed in the same timeframe, for instance using C++11 features to prettify the code and introducing a single, cross platform build system. But those two bugs should be absolutely required for releasing 1.0, and the release should be made shortly after they're addressed. Otherwise if we want to release another major version before fixing them, we would go to 0.92.
2013/10/24 Guillermo Espertino (Gez) <gespertino@...400...>:
I think 0.5 sounds better, and gives place for four .1 increments before 1.0. After so many years of 0.4x, changing to 0.5 already communicates an important change.
Software with automatic version comparison, such as dpkg, will think that 0.5 is a lower version than 0.49, and this will make life hard for packagers. (Note that dpkg --compare-versions returns a non-zero status when the condition is false.)
$ dpkg --compare-versions 0.5 ge 0.49 $ echo $? 1
After 0.91, we can release 0.92 if the two bugs are still not fixed (but I hope it won't come to that).
Regards, Krzysztof
On Thu, Oct 24, 2013 at 06:34:46AM -0700, Josh Andler wrote:
That sounds like a solid compromise imho... especially if the cycle is dedicated to those two things and bug fixes (NO NEW FEATURES). As it would be possible to get a release out relatively fast if those were purely the focus. I'm pretty sure people who have problems with either of those would say they're "special release" worthy.
Cheers, Josh
On Thu, Oct 24, 2013 at 6:15 AM, Krzysztof Kosiński <tweenk.pl@...847...0...> wrote:
How about this:
- We rename Inkscape 0.49 to Inkscape 0.91
- In the next cycle, we actively work to address the two major bugs
(flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
Regards, Krzysztof
Sounds good to me as well. I almost suggested this myself but thought people might be too wedded to 0.49 as the next release number. Adding cairo is certainly a big enough change to justify a version number jump.
People will be really excited to know 1.0 is in the works. Why not get it started.
No new features sounds like a good approach for the next (0.92?) cycle, but there should be an exception process. If someone has done provably good work on a side branch, kept everyone well informed about it, verified it breaks nothing, and users want it, then having some way to propose it for inclusion might help anxious developers without having to compromise on quality.
Bryce
El 24/10/13 10:15, Krzysztof Kosiński escribió:
How about this:
- We rename Inkscape 0.49 to Inkscape 0.91
- In the next cycle, we actively work to address the two major bugs
(flowtext and coordinates) 3. When those are addressed, we release Inkscape 1.0
From 0.48 to 0.91 is a weird increment. Why not just 0.9?
I think 0.5 sounds better, and gives place for four .1 increments before 1.0. After so many years of 0.4x, changing to 0.5 already communicates an important change.
If none of the two major bugs are addressed for the next version, you could release 0.6 and still have place for three more versions. If they are, you can jump from 0.5 to 1.0 and it would also make sense.
Regarding using a date, I don't think it's a good idea if there are no planned releases. Autodesk and Ubuntu, for instance, use that version number scheme, but they have rather fixed release dates (Autodesk usually releases a new version of their bloatware once a year, and Ubuntu has planned releases each april and october). I don't think that numbering would work fine for projects like Inkscape. two releases in a year would look like the second is a revision of the first; one version each 3 years would look like lack of expected updates.
Gez.
participants (10)
-
Alex Valavanis -
Bryce Harrington -
Chris Mohler -
Dmitry Kirsanov -
Guillermo Espertino (Gez) -
Jared Meidal -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Steren