Adib,
I think we all want 0.47 out the door just as bad. ;)
I completely agree about gimp's newer handling of files, and theoretically it should be very easy for us to make the changes quickly and easily. For everyone's sake, it's a better approach that we should share with the gimp.
Perhaps cmake support should be held off for that longer 0.49 cycle since it's a type of refactoring. I wouldn't be opposed to it for 0.48, but have no idea how far off it really is at this point.
I'm pretty sure the connector tool request you have was done in the SoC work that is planned to be merged.
The short response is, 0.48 around Christmas is just not possible. Mid-December Feature Freeze could be possible though if 0.47 is out in a month though.
One last thing to shoot for for 0.48 would be for the LPEs that could take advantage of the new node tool to be updated (such as envelope).
Cheers, Josh
On Sun, 2009-09-13 at 14:48 +0200, the Adib wrote:
Josh,
thanks for picking this up. However I really want this 0.47 out the door!
I want for 0.48 (adib didn't check the roadmap do):
- file dialogues as in Gimp - put all the non svg formats into export/import
- cmake support
- connector tool width rounded corners
- uniconvertor that can handle text
- release 0.48 around christmas ....
the Adib.
On Sun, Sep 13, 2009 at 8:16 AM, Joshua A. Andler <scislac@...400...> wrote:
Hey All,
Kinda lengthy, but, please read and respond if you intend to be involved in the upcoming releases.
In numerous off-list discussions with a handful of devs and contributors it seems like there is a favored route for the upcoming releases. 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.
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).
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. 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).
Any objections or concerns that people feel the need to voice? Anything that other people would like to see during these releases?
Cheers, Josh
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel