On Tue, Jun 21, 2011 at 12:43 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
On 2011-06-20 23:05, Krzysztof Kosiński wrote:
Cairo rendering merged in revision 10326.
2011/6/20 ~suv <suv-sf@...58...>:
Maybe the devlibs for Windows could be branched into stable and devel:
- stable for (bug-fix) releases
- devel for development builds from current trunk
Hmm... I should have done that a long time ago :) I can upload r23 (before I committed dev snapshot Cairo) as a separate branch to be used for stable.
I'm not against that if it's handled like Inkscape releases (so "stable" is just a kind of snapshot in time of a revision known to be more or less good), but once the Cairo branch is merged we'll need the new Cairo anyway... And until the next Inkscape release the devlibs are "devel" by default (more or less). If the "old" Cairo doesn't work satisfactorily with the cairo branch and the "new" cairo isn't stable enough for general use then we simply have a problem and shouldn't be merging the cairo branch at this point (very, very regrettably).
On the other hand, if the cairo branch only has very minor problems when used with the "old" cairo and/or the "new" cairo is generally usable, then what's the problem? Also, if the only problem is that the Windows builds of cairo aren't up-to-date enough yet, I'll gladly have a look to see if we can't just compile the latest version and use that.
BTW, the reason I'm not jumping at the opportunity to branch the devlibs is that having stable and devel branches tends to make stable branches outdated and devel branches unstable. Neither is very appealing to me. I think Inkscape generally has a very good policy of trying to ensure that trunk is more or less constantly usable.
In this case, we're looking to push 0.48.2 in the very near future. We won't have sufficient testing time prior to that release to deem things kosher (in fact, given the push to have it be our stable branch, we won't). We will however have time with the unstable/newly stable libs to see if there are any blockers for when our 11.X release rolls around.
The big win here is that we can possibly prevent stuff like tablet support on Windows getting broken frequently. We can have the ability to really mess around and ensure that the latest and greatest continues to meet our needs (with tablets, neither 0.48.1 nor current devlibs work right with my win testing of a wacom).
Cheers, Josh