Sure... I appreciate that business/academic users will want to run stable LTS/enterprise versions of distros.  However, they also usually either stick with old versions of applications or spend large sums of money on upstream/distro maintenance contracts for back-porting business-critical software, whereas Inkscape has no paid developers.  As such, we rely on voluntary developers working at home on their own PCs to maintain compatibility with old distros, so unfortunately it's quite a difficult task!

Speaking personally, I try my best to avoid breaking compatibility but it's very hard without good CI.

Perhaps, then, part of the solution is to offer paid maintenance contracts?  I can think of a couple of the other devs who would be willing to support users in this way.

AV

On 24 July 2017 at 17:57, mathog <mathog@...1176...> wrote:
On 22-Jul-2017 01:14, Michael Soegtrop via Inkscape-devel wrote:
My problem is that in the last week
quite a few changes came in, which are not compatible with Debian 8:

- Requirement for CMake 3.2+ (Debian 8 has 3.0.2)
  specific syntax of add_custom_target

 Developers who do not work on production systems frequently do not give much thought to backwards compatibility.  These developers often run the absolute latest releases of Fedora or Ubuntu, and so most of the packages they see are on the bleeding edge of the release set.  Machines used in production environments in business and academia usually run much more conservative and stable releases, and that translates to much older, versions of software.  As an example, Centos 6 (basically the same as RHEL 6 but free), a fairly common platform in scientific circles, was released in 2011, full updates just ended in May, and security updates will continue until November 2020.   Version 6.9, the last update in that version, currently has cmake 2.8.12 and it will never have an official upgrade beyond that.  2.8.12 was released Oct 2013, so is not quite five years old, but close. Centos 7.3 also has cmake 2.8.12.  Cmake 3.2.1 (was there a 3.2.0?) was released Mar 2015, which in my view is much too recent to require.

As a rule of thumb, if there is a requirement for a library version, language version, or tool which is younger than 5 years old it will almost certainly not be satisfied in these environments with default packages.  It _may_ be possible to find alternative packages, but a simple download, build, and run will not work, and hours to days scrounging up the newer requirements will need to be expended.  Now I can already hear some developers screaming about using archaic tools, but that's the difference between having to work in production environments and messing about with one's own computers, where that constraint does not exist.  For serious software if the oldest green check for any of the OS's here:

   https://linuxlifecycle.com/

does not have the version of the package you want to use, then that package is too recent to employ in a project.  That's how I feel, anyway.
For Inkscape I would add in the same constraint for Mingw and whatever environment people are using to build on OS X.

Whatever new cmake feature that 3.2 provides can certainly be worked around using older versions.  That is almost always the case with the latest and greatest of every package.  The primary, and quite rare, exception being where some showstopper of a security bug exists and the only way around it is to use a later release.

Regards,

David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...142...ge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel