[Scons-dev] Should we remove python 3.5 from our CI tests

[Mats Wichmann]

>> If the model is "support whatever is supported in active Linux
>> distrubtions", that's a valid point. In fact, by that measure, since
>> long-term distributions like RHEL7 and Ubuntu 14.04 use 3.4, that
>> should
>> be on the support/CI list as well.
> 
> The distros package SCons and well as Python, so there doesn't seem to
> be a problem.
> 
>>> Are you going to drop Python 2 support too?
>>
>> 2.7 is still a supported version, even at python.org.

There aren't really any easy answers.  I think I expressed earlier
support for dropping CI support for 3.5, but...

scons is a tool used to build projects, not really a part of the
projects. "Users" become interested in scons itself when there's
something they can't do with scons, so they want a new version that
improves that situation (okay, speaking for myself :)  Otherwise,
changing versions aren't very interesting to them.

obviously a buildsystem has to do more than work flawlessly on bleeding
edge systems a developer may be running "at his desk". it also has to
work on external environments that may not be so up to date - QA teams,
auto-provisioned CI infrastructure, etc.  In fact "not so up to date"
can be surprisingly old - I think people have already mentioned here
that there are "official" setups that default to Ubuntu 12.04 (which,
even as an LTS, is officially out of support); SLES and RHEL and CentOS
systems that are a half-decade or more out of date, etc.  One of the
setups in the CI system we use is pegged to scons 2.1.0 because that's
the available rpm package from the official source used for provisioning it.

As long as the builder gets its Python and scons from the same place
(Linux distro packaging), nothing is too likely to break unexpectedly;
you can count on those being tested together. But other builders don't
necessarily have a consistent source - Windows doesn't include either
Python nor scons; MacOS has a Python but not scons, etc. So those have
to be provisioned up from an external source and that may mean there are
occasional surprises if those sources move along.  In some (most?) cases
you can peg your scons to a version; if that is not done, problems.

But can't support a matrix of everything.  I think many "free for open
source projects" CI systems tend to start asking for money if you try to
throw too many combinations at them.  At one point we wanted to
integrate a Coverity run into our CI system, but that one severely
limits how many scans-per-time-period you can submit.  So the idea of
each scons version having a minimum and maximum Python version, and
those are the versions that are part of CI, makes sense to me.