>> 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@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
