On Sun, Aug 24, 2014 at 04:19:23PM +0200, Johan Engelen wrote:
On 24-8-2014 9:02, Tavmjong Bah wrote:
On Sat, 2014-08-23 at 13:12 -0700, Jon A. Cruz wrote:
On Sat, Aug 23, 2014, at 01:30 AM, Alex Valavanis wrote:
@Jon, it wouldn't cut anyone off since all current Linux distros, devlibs & OSX are able to build the experimental Gtk+ 3 flavour.
So requiring GTK3 is clear on the Ubuntu front since 12.04LTS does include it in their repo. RHEL 5 and RHEL 6 do not, while the newly introduced RHEL 7 does. RHEL 5 can probably be safely regarded as "too old", but RHEL 6 is still in the middle of of its initial production phase which does not end until Q2 of 2016. Given that RHEL 7 is still at "dot 0", those using RHEL probably are not into a transition yet from 6 to 7.
And definitely keep in mind that at least a large portion of our targeted end users are not highly technical linux coders, but those with the need to create graphics, such as artists and designers.
True, but the long-term releases are generally not targeted to this group. LTR's are more used on servers where long-term stability is important. In my previous life as a physicist, we would have the latest release on our desktops/laptops while our analysis farms would be running a LTR.
Also, don't forget that 0.92 isn't going to happen tomorrow...
I agree. What I gather from mails to our list, I think availability of GTK3 is not a problem for 0.92 onwards. This is similar to moving to C++11. The explanation is simply that working on an LTR/LTS system is not marriable (in general) to using supernew/trunk Inkscape; it would conflict (imho) with the "LTS" part of that system.
I get where you're coming from, but I don't think that's a good generalization to make; there are desktop users who stick with the LTS yet still want to see updates for graphical applications. Hell, we were backporting the X stack to LTS releases for *gamers*.
But the key point seems to be that 0.91 has holding off on a variety of potentially de-stabilizing changes in order to ensure a stable release. So starting with 0.92 we *have* to start allowing some of these big changes through.
Where we could get into trouble is if when 0.92 opens up we try to change too many big things at once. Instead, lets plan out a roadmap for 0.92, 0.93, etc. and space out these changes a bit. If each release focuses on just one or two major changes, then I think it should be more feasible to accelerate the release schedule as well; if we could get it to one release per quarter that might be closer to ideal.
Bryce