Joshua A. Andler wrote:
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... if we're lucky, further text tool work could make it in too. 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... this is part of why the stability and functionality of this release is critical (trunk may need to have issues for a bit after 0.48 drops).
Great idea. I still vote for git, but since I don't plan to do the work myself I will happily use whatever I get!
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 understand the general "it's an experiment" and "we can't promise a stable api" issues, but, the cord needs to be cut at sometime and I think this is fair notice. Also, this is how gimp is being developed with babl and gegl... so it is doable and a non-issue (I use unstable gimp too, so I know from experience of having to update them both when I want to update gimp).
(I hope someone who is more experienced will chime in here.) Is it meaningful for this discussion to mention that babl, gegl and gimp are C projects. 2geom and inkscape are C++ and it was my understanding that there were special problems and considerations for C++ library versioning and compatibility. Perhaps we could strongly recommend that packagers package inkscape and 2geom together with 2geom being built as a dynamic library named specially so it won't conflict with other uses of 2geom on the system. This would of course only be an intermediate step and only if the 2geom developers and resident C++ experts find it necessary.
Aaron Spike