On Sat, 2009-09-12 at 23:16 -0700, Joshua A. Andler wrote:
Have a short dev cycle for 0.48 which needs to be pretty solid (even if made so over time by point releases... I will commit to continuing a couple of those). Then we go for another long-ish refactoring cycle for 0.49.
One thing that Debian is considering is fixed dates for freezes. So they'd do a freeze on a fixed schedule, and then release when it's ready. I'm curious if this might work for us long term, certainly with a DVCS we'd have more flexibility there.
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk. This needs to be discussed and resolved ASAP, svn is not good enough for our needs any longer, period. Then, we drop in this year's SoC work, the spray tool, any big things that are far enough along in people's working copies, polish up everything and fix all new issues discovered from 0.47...
I just want to say here that if we're going to switch to a DVCS, I think we should switch BEFORE merging the SoC projects in. We'll get a better version history there and it'll also make the merges better.
For 0.49 the thought is to attempt to ditch our copy of gdl in favor of submitting the necessary bits upstream and using it as a proper library.
+1, the GDL guys have also offered some help with this. It may be possible for 0.48 even.
It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library.
Yes! I don't believe there are any more C++ issue with this now that they've spec'd the ABI.
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
I'd like to see if we can't do the same type of library splitouts with libavoid and libcoroco...
Also, I'd like to make it so that we're a little more independent for extensions as well. That way we could release extensions in a different release schedule than the core Inkscape.
--Ted