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

[Bill Deegan]

While neither windows nor MacOS include SCons, there are defacto package
managers for both:
Windows: Chocolatey - no scons, but multiple python versions
MacOS: macports and homebrew (both include scons and multiple python
versions

Thus far we're not having issues with CI running on 2.7.x, 3.5.x, 3.6.x,
(and now) 3.7.x

For those who haven't been around quite as long, SCons used to support back
to Python 1.5.7 and it took some convincing to get the developers (who
included myself and I was a proponent) to move forward.  I think we moved
first to 2.2, then 2.4, then 2.5, then 2.7.x & 3.5+.

At this point the burden of maintaining our current Python support isn't to
high so no need to start dropping versions of python still in wide usage
and still supported by Python.org..

Mats - As an aside I currently have Coverity running for a client via CI.
(Its either gotten faster or machines have or both, years ago the coverity
build on 3.3M line c/c++ project was 29 hours, and we still ran it via
CI).  Both in their own Coverity builder.

Regardless I think we've covered the bases in this discussion and let's
revisit Jan 2019 to see what makes sense.
The thoughtful discussion is much appreciated!

If we found Python 3.x provided some significant performance advantage that
we could only get by dropping older versions that might be compelling.

-Bill


On Sat, Jul 21, 2018 at 11:56 AM, Mats Wichmann <mats at wichmann.us> wrote:

>
> >> 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.
>
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20180721/96423fe5/attachment.html>