Joshua A. Andler-2 wrote:
Essentially, make 0.47 "good enough" (avoid point releases if possible). 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.
A sound plan, I agree :)
For 0.48 the thought is to... move to a DVCS before any code changes are made in trunk.
I vote for bzr. There is hardly anything to learn with respect to SVN (you can use the exact same commands but substitute 'svn' for 'bzr') and the Launchpad integration is a big benefit. For example, branches with tentative fixes could be attached to complicated bugs.
Additionally, if we could get cairo work in a
branch (under said DVCS) during this cycle, it would be excellent to possibly get something to drop in for the 0.49 dev cycle
Is there any plan on how we're going to do this? Do we write a new C++ library that is similar to libnr but nicer to work with and uses Cairo and 2Geom internally, or rip out rendering code from libnr and replace it with Cairo operations?
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. In addition to our modifications I would like to see support for creating dock items with named icons.
It has been said before, it would be really excellent if we could have 2geom be broken out and used as a proper library.
I think this could be done when 2Geom has something resembling a coherent API :) Right now some files are just copies of old Inkscape code (for example bezier-utils.h) and several objects are ugly (rtree.h). At a minimum, this could be postponed until 0.49.
Regards, Krzysztof Kosiński