GTK+ version dependency
Hi All,
As we move towards GTK3 compatibility , we're going to run into a lot of backward-compatibility issues. For easy cases like bug #800565 [1], we can just add code alternatives, but there are other situations where this isn't really desirable. An example would be fixing deprecated symbols in our copy of GDL... I'd really prefer to import changes from upstream rather than increasing the size of our diff any further. However, the upstream fix for one of the GDL issues requires gtk+ 2.22.
The question is when to start bumping the gtk+ version requirement for Inkscape? If we want to support LTS linux distros, we could be waiting a **very** long time. For example... Ubuntu Lucid (LTS) has no GTK+3 library, and only gtk+ 2.20, and is supported until April 2013.
Options include... 1. Keep our linux LTS-release support rigorously; don't make any gtk code updates that introduce a gtk > 2.20 dependency (unless there are easy code-alternatives for backward compatibility). Eventually move on when common LTS distros reach end-of-life.
2. Gradually inch forward with dependency versions. Drop linux LTS-release support for trunk, but maintain support for all current non-LTS distro versions (e.g. Ubuntu Maverick and higher).
3. Charge ahead mercilessly towards compatibility with the current stable GTK version (currently 3.2). Break support for linux distributions as required, and laugh heartily in the faces of the grieving users.
Any thoughts?
AV
I'd vote 2 or 3. I'm merciless for the record, but after the poll I did with devs and translators I feel 2 is a kinder option.
Cheers, Josh On Dec 18, 2011 4:58 PM, "Alex Valavanis" <valavanisalex@...400...> wrote:
Hi All,
As we move towards GTK3 compatibility , we're going to run into a lot of backward-compatibility issues. For easy cases like bug #800565 [1], we can just add code alternatives, but there are other situations where this isn't really desirable. An example would be fixing deprecated symbols in our copy of GDL... I'd really prefer to import changes from upstream rather than increasing the size of our diff any further. However, the upstream fix for one of the GDL issues requires gtk+ 2.22.
The question is when to start bumping the gtk+ version requirement for Inkscape? If we want to support LTS linux distros, we could be waiting a **very** long time. For example... Ubuntu Lucid (LTS) has no GTK+3 library, and only gtk+ 2.20, and is supported until April 2013.
Options include...
- Keep our linux LTS-release support rigorously; don't make any gtk
code updates that introduce a gtk > 2.20 dependency (unless there are easy code-alternatives for backward compatibility). Eventually move on when common LTS distros reach end-of-life.
- Gradually inch forward with dependency versions. Drop linux
LTS-release support for trunk, but maintain support for all current non-LTS distro versions (e.g. Ubuntu Maverick and higher).
- Charge ahead mercilessly towards compatibility with the current
stable GTK version (currently 3.2). Break support for linux distributions as required, and laugh heartily in the faces of the grieving users.
Any thoughts?
AV
[1] https://bugs.launchpad.net/inkscape/+bug/800565
Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2011/12/19 Alex Valavanis <valavanisalex@...400...>:
The question is when to start bumping the gtk+ version requirement for Inkscape? If we want to support LTS linux distros, we could be waiting a **very** long time.
LTS distros have their own LTS versions of Inkscape.
Of course it would be nice to work everywhere, but if you have an LTS distro, chances are that cutting edge features are not your focus. Installing a new version of Inkscape on such a system is kind of self-defeating: you want stability and consistency, but then you give it up by installing unstable software. Therefore I don't think we should hold back development for this use case.
Regards, Krzysztof
On Dec 18, 2011, at 5:39 PM, Krzysztof Kosiński wrote:
2011/12/19 Alex Valavanis <valavanisalex@...400...>:
The question is when to start bumping the gtk+ version requirement for Inkscape? If we want to support LTS linux distros, we could be waiting a **very** long time.
LTS distros have their own LTS versions of Inkscape.
Of course it would be nice to work everywhere, but if you have an LTS distro, chances are that cutting edge features are not your focus. Installing a new version of Inkscape on such a system is kind of self-defeating: you want stability and consistency, but then you give it up by installing unstable software. Therefore I don't think we should hold back development for this use case.
I've seen a large portion of users that have a different focus there.
They aren't into bleeding edge OS updates, but instead are focused on applications themselves. That is, many people don't want to jump the OS each and every time they can, but they do like to keep apps moving.
This often comes from experience with things breaking. That is not only for Linux, but for mac users too. One extreme case was when I tried to update to a non-stock compiler (in which case the entire ports system had to get uninstalled and replaced to get back to a working state).
So for many (especially non-Gentu using) people, there is a distinction between upgrading apps and upgrading OS/compiler, etc. So they like a stable OS, but do look to improve the apps when they can.
On Mon, 2011-12-19 at 02:39 +0100, Krzysztof Kosiński wrote:
Of course it would be nice to work everywhere, but if you have an LTS distro, chances are that cutting edge features are not your focus.
I'm running LTS ubuntu 10.04 - I don't want to upgrade my OS - but I do want to run the latest inkscape - which I wasn't able to do for quite some time due to a cairo depend... Thankfully Cafuego was able to do some backport jiggery pokery and I'm reasonably up to date again.
I understand the urge to move forward, and agree we don't want to unnecessarily hold up progress - but I think you need to be very careful about your assumptions.
On Dec 18, 2011, at 4:57 PM, Alex Valavanis wrote:
- Gradually inch forward with dependency versions. Drop linux
LTS-release support for trunk, but maintain support for all current non-LTS distro versions (e.g. Ubuntu Maverick and higher).
I think this around the right approach... given decent set of definitions of course.
Where we usually see issues is with exactly what "current" means. To some it means "the latest and greatest of bleeding edge of the distro". To others it means "versions that have not yet seen end-of-life."
A good choice can be to avoid explicitly excluding LTS releases.
In general we end up with far more concern about "getting tied down with compatibility" than comes up in real life. Normally we've seen that either a bit of minor #ifdef tweaking can give proper fall-back functionality, or in many cases just not use new functionality when built for older libs.
We have a major break with certain cairo issues (aka the need for updated libs as a requirement is not an easy one to make backards compatible), but that is the exception rather than the rule.
We also have the wiki page to try to bring the questions out of the abstract and to be more concrete.
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies
I'm generally happiest when we don't just block users accidentally. To bring that back to your example, we can take a look at the gdl need. Fedora and OpenSUSE seem fine, and I'd then say that Canonical has messed things up enough for their own users that dropping Lucid support for newer Inkscape is not too hard. Hopefully once the whole Unitly/GNOME3 shift has settled out we should be able to get back on track with better version support.
On 19 December 2011 05:33, Jon Cruz <jon@...18...> wrote:
We have a major break with certain cairo issues (aka the need for updated libs as a requirement is not an easy one to make backards compatible), but that is the exception rather than the rule.
We also have the wiki page to try to bring the questions out of the abstract and to be more concrete.
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies
I've had a go at updating the some of the dependencies on that page. I don't have time at the moment to do more, but if anyone can update any, that would be great.
A quick check indicates that the existing cairo >=1.10 requirement actually breaks support Inkscape trunk for quite a few older linux releases anyway. All of the tracked distros that provide the required version of Cairo also give us gtk+ >= 2.22. I therefore propose going ahead with a dependency bump to gtk+ 2.22.
On 19-12-2011 1:57, Alex Valavanis wrote:
Hi All,
As we move towards GTK3 compatibility , we're going to run into a lot of backward-compatibility issues. For easy cases like bug #800565 [1], we can just add code alternatives, but there are other situations where this isn't really desirable. An example would be fixing deprecated symbols in our copy of GDL... I'd really prefer to import changes from upstream rather than increasing the size of our diff any further. However, the upstream fix for one of the GDL issues requires gtk+ 2.22.
The question is when to start bumping the gtk+ version requirement for Inkscape? If we want to support LTS linux distros, we could be waiting a **very** long time. For example... Ubuntu Lucid (LTS) has no GTK+3 library, and only gtk+ 2.20, and is supported until April 2013.
Options include...
- Keep our linux LTS-release support rigorously; don't make any gtk
code updates that introduce a gtk> 2.20 dependency (unless there are easy code-alternatives for backward compatibility). Eventually move on when common LTS distros reach end-of-life.
- Gradually inch forward with dependency versions. Drop linux
LTS-release support for trunk, but maintain support for all current non-LTS distro versions (e.g. Ubuntu Maverick and higher).
- Charge ahead mercilessly towards compatibility with the current
stable GTK version (currently 3.2). Break support for linux distributions as required, and laugh heartily in the faces of the grieving users.
Any thoughts?
For who doesn't know yet (I didn't until I bought a tablet): We already doing the "laugh heartily in the faces of the grieving users". Considering the 1+ million Windows downloaders of 0.48.2, it is quite likely to affect more people than just me.
Ciao, Johan
On Mon, Dec 19, 2011 at 1:43 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 19-12-2011 1:57, Alex Valavanis wrote:
Hi All,
As we move towards GTK3 compatibility , we're going to run into a lot of backward-compatibility issues. For easy cases like bug #800565 [1], we can just add code alternatives, but there are other situations where this isn't really desirable. An example would be fixing deprecated symbols in our copy of GDL... I'd really prefer to import changes from upstream rather than increasing the size of our diff any further. However, the upstream fix for one of the GDL issues requires gtk+ 2.22.
The question is when to start bumping the gtk+ version requirement for Inkscape? If we want to support LTS linux distros, we could be waiting a **very** long time. For example... Ubuntu Lucid (LTS) has no GTK+3 library, and only gtk+ 2.20, and is supported until April 2013.
Options include...
- Keep our linux LTS-release support rigorously; don't make any gtk
code updates that introduce a gtk> 2.20 dependency (unless there are easy code-alternatives for backward compatibility). Eventually move on when common LTS distros reach end-of-life.
- Gradually inch forward with dependency versions. Drop linux
LTS-release support for trunk, but maintain support for all current non-LTS distro versions (e.g. Ubuntu Maverick and higher).
- Charge ahead mercilessly towards compatibility with the current
stable GTK version (currently 3.2). Break support for linux distributions as required, and laugh heartily in the faces of the grieving users.
Any thoughts?
For who doesn't know yet (I didn't until I bought a tablet): We already doing the "laugh heartily in the faces of the grieving users". Considering the 1+ million Windows downloaders of 0.48.2, it is quite likely to affect more people than just me.
The bug tracker and numerous forum posts confirm your guess.
Cheers, Josh
participants (6)
-
Alex Valavanis -
Donna Benjamin -
Johan Engelen -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński