Bryce,
We could road map this to create an expected structure.
Get 0.93 out the door with Gtk3 and all the problems that are likely caused by it
Immediately state the next release will be 1.0, no 0.94 hedging release.
Then we operate 0.93 to 1.0 like a super long freeze with bug fixes and regression testing and maybe a few non-feature improvements.
But this kind of thing is a matter for leadership and that may fall on yourself or who ever wants to be commander in the batter for the 1.0 release.
Best Regards, Martin Owens
On Fri, 2017-10-20 at 23:08 -0700, Bryce Harrington wrote:
On Sat, Oct 21, 2017 at 12:52:46AM +0200, Marc Jeanmougin wrote:
In the non-UNIX world, versions 0.something is usually associated with "beta". If we manage to have a really stable 0.93 (say, as stable as 0.48.5 and as fast as it), with few regressions, an easily css-customizable UI on windows that also would look right on 4k screens, and ideally also works nicely on macs, it might be worth it to call our 0.93.1 … "1.0" (Yeah, I listed all the main challenges I can think of)
Certainly, and in fact that's the plan -- that's why we jumped numbers from 0.48 up to 0.9x. Intent has been to get to 1.00 "soonish".
The question is what precisely needs to be achieved, and when we first discussed it, the list was pretty daunting. However the good news is we've checked off a bunch of the items... gtest, cmake, git/gitlab, gtk3, and so on.
There's still work to get the gtk3 changes looking and working properly, and I'm hoping Tav can build us a good todo list for what should be focused on for 0.93 (and maybe 0.94?)
You mention stability and elimination of regressions, which likely is going to be a big expectation to deliver for a 1.00 release, and so should be given lots of attention. I wish I had a better handle on the size and scope of this work; I worry it could be overwhelmingly huge. Maybe worth making a prioritized list. I suppose it depends a lot on how much devel power we have available for working on the bugs (and how we can augment it).
At some point we'll want to taper down on feature development work, to avoid introducing new regressions. That'll be hard because new features are always exciting and the pressure to include them is very strong. Refactoring and architectural adjustment work can also be potential sources of regressions.
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel