Re: [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  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@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [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.



___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Jason Kenny]

I would suggest if you want to drop versions of python to test that we at the 
minimum test:


  1.  Lowest version of python 2 we support
  2.  High version of python 2 we support
  3.  Lowest version of python 3 we support
  4.  Highest stable version of python 3 we support

We would want to test others versions because of some behavior it shows that 
breaks something, or because we want more coverage for finding something.

My personal option is that testing more if it cheap to do so, is always better. 
It never hurts and can find unexpected issues.
At the very least test the ranges. Hope everything else in the middle will be 
fine… well at least until one knows better. Then add that to the testing until 
it falls off the minimum supported version.

Jason

From: Scons-dev  On Behalf Of Bill Deegan
Sent: Friday, July 20, 2018 10:20 PM
To: SCons developer list 
Subject: Re: [Scons-dev] Should we remove python 3.5 from our CI tests

Pretty certain Gary's with me in saying,
SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
Most likely through (at least) the end of 2018.

I know many who actively participate in SCons community live on the leading 
edge of OS and Python releases but many users do not.
Also, there are still some rough edges to our Python 3 support. Until it's rock 
solid (and no one has found an issue for a while), dropping py 2.7 would be 
unwise.


-Bill
SCons Project Co-Manager.

On Fri, Jul 20, 2018 at 4:11 PM, Jonathon Reinhart 
mailto:jonathon.reinh...@gmail.com>> wrote:
> True but who uses Debian Stable for anything relating to software
> development, it is a server distribution.

I'm not sure where you got the idea that Debian is a "server
distribution". Lots of people use Debian as a desktop OS, and my team
uses Debian for software development.

I think SCons would be making a serious mistake if it dropped support
for Python 3.5. Just because the distro is using an older version of
SCons, doesn't mean that SCons shouldn't support the latest version of
Python available on the system.

This is particularly troublesome for me as I consider putting together
a new build image, based on Debian 9, but with latest SCons installed
from source.

I'm all for cleaning up old cruft, but it seems like removing support
for a version of Python that's less than 3 years old seems a bit
aggressive.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Dirk Baechle]

Hi there, 

(yes, I'm still alive ;) ) +1 from me for, at least trying to provide, some 
backward compatibility to Python 2.7.x. As long as the impact on current 
development is low, we should try to bring the new SCons stuff also to people 
using older Python distros.

Side note: at work (ATC context) I'm still stuck to Python 2.6 and SCons 2.4-1 
IIRC, under SLES11 SP2. :)

Best regards, 

Dirk


Am 21. Juli 2018 13:43:07 MESZ schrieb Gary Oberbrunner :
>Russel says:
>
>Python 2 is the millstone for SCons 3.
>
>I've been using 3.6 for all recent projects and loving it (async,
>f-strings, etc.), but what weight are we really carrying by supporting
>2.x?
>Seems to me like most 3.6 features can be detected at runtime while
>still
>keeping back compat without too much extra work. But I may be missing
>something.
>
>-- Gary
>
>On Sat, Jul 21, 2018 at 7:37 AM Russel Winder 
>wrote:
>
>> On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
>> > Pretty certain Gary's with me in saying,
>> > SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
>> > releases.
>> > Most likely through (at least) the end of 2018.
>>
>> You can add me to agreeing with that.
>>
>> > I know many who actively participate in SCons community live on the
>> > leading
>> > edge of OS and Python releases but many users do not.
>> > Also, there are still some rough edges to our Python 3 support.
>Until
>> > it's
>> > rock solid (and no one has found an issue for a while), dropping py
>> > 2.7
>> > would be unwise.
>>
>> I see your finger pointing at me. :-)
>>
>> We have had not dissimilar maintenance debates in the Apache Groovy
>> community, especially now JDK is updated every 6 months instead of
>> every 6 years. Clearly there is a need to support people using
>ancient
>> three year old systems. Debian Stable and Ubuntu LTS really set the
>> timescales here, and the Python versions. Except that Travis-CI
>appears
>> to think using the most ancient Ubuntu LTS they can is a good thing.
>>
>> But then come the issues at the heart of the matter: If people are
>> using three or five year old platforms, will they be using the very
>> latest version of SCons? If they want the very latest SCons why can't
>> they install the very latest Python? If they are happy with the three
>> year old Python will they actually be happy with the three year old
>> SCons? If a distribution provides Python and SCons why is there any
>> interest in them updating anything?
>>
>> Groovy used to have a "we must be totally backward compatible"
>> obsession that was over the top, especially for me. Over the last
>year
>> the policy has changed towards something much better, and which has
>> allowed Groovy to progress much better in a highly dynamic world.
>>
>> OK so Java has the big difference that you distribute compiled
>> artefacts and there are only link time issues, whereas Python is
>> distributed as source so everything is compile time issues. But the
>> Groovy team have now begun to accept that "backward compatibility"
>can
>> be taken too far. For each major version of Groovy a lower limit is
>now
>> set and if people are not prepared to update their Java, then they
>have
>> to use the last version of Groovy that works with that version of
>Java.
>>
>> Python 2 is the millstone for SCons 3. The question is whether there
>> will be a 2.7.16 or whether 2.7.15 is really the last version. Also
>> will an organisation break ranks with PSF policy and pick up Python
>2.7
>> and keep it going? Would that matter for SCons?
>>
>> I can fully understand sticking with 3.5 at this time, but SCons
>> versions must be allowed to change the minimum Python version. Should
>> SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
>> then people not on Python 3.6 simply stay with SCons 3.0.X.
>>
>> For me this is all about consistency: you can't demand cutting edge
>> SCons unless you are prepared to use cutting edge Python.
>>
>> --
>> Russel.
>> ===
>> Dr Russel Winder  t: +44 20 7585 2200
>> 41 Buckmaster Roadm: +44 7770 465 077
>> London SW11 1EN, UK   w: www.russel.org.uk
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>
>
>-- 
>Gary

-- 
Sent from my Android with K-9 Mail.___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Gary Oberbrunner]

Russel says:

Python 2 is the millstone for SCons 3.

I've been using 3.6 for all recent projects and loving it (async,
f-strings, etc.), but what weight are we really carrying by supporting 2.x?
Seems to me like most 3.6 features can be detected at runtime while still
keeping back compat without too much extra work. But I may be missing
something.

-- Gary

On Sat, Jul 21, 2018 at 7:37 AM Russel Winder  wrote:

> On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
> > Pretty certain Gary's with me in saying,
> > SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
> > releases.
> > Most likely through (at least) the end of 2018.
>
> You can add me to agreeing with that.
>
> > I know many who actively participate in SCons community live on the
> > leading
> > edge of OS and Python releases but many users do not.
> > Also, there are still some rough edges to our Python 3 support. Until
> > it's
> > rock solid (and no one has found an issue for a while), dropping py
> > 2.7
> > would be unwise.
>
> I see your finger pointing at me. :-)
>
> We have had not dissimilar maintenance debates in the Apache Groovy
> community, especially now JDK is updated every 6 months instead of
> every 6 years. Clearly there is a need to support people using ancient
> three year old systems. Debian Stable and Ubuntu LTS really set the
> timescales here, and the Python versions. Except that Travis-CI appears
> to think using the most ancient Ubuntu LTS they can is a good thing.
>
> But then come the issues at the heart of the matter: If people are
> using three or five year old platforms, will they be using the very
> latest version of SCons? If they want the very latest SCons why can't
> they install the very latest Python? If they are happy with the three
> year old Python will they actually be happy with the three year old
> SCons? If a distribution provides Python and SCons why is there any
> interest in them updating anything?
>
> Groovy used to have a "we must be totally backward compatible"
> obsession that was over the top, especially for me. Over the last year
> the policy has changed towards something much better, and which has
> allowed Groovy to progress much better in a highly dynamic world.
>
> OK so Java has the big difference that you distribute compiled
> artefacts and there are only link time issues, whereas Python is
> distributed as source so everything is compile time issues. But the
> Groovy team have now begun to accept that "backward compatibility" can
> be taken too far. For each major version of Groovy a lower limit is now
> set and if people are not prepared to update their Java, then they have
> to use the last version of Groovy that works with that version of Java.
>
> Python 2 is the millstone for SCons 3. The question is whether there
> will be a 2.7.16 or whether 2.7.15 is really the last version. Also
> will an organisation break ranks with PSF policy and pick up Python 2.7
> and keep it going? Would that matter for SCons?
>
> I can fully understand sticking with 3.5 at this time, but SCons
> versions must be allowed to change the minimum Python version. Should
> SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
> then people not on Python 3.6 simply stay with SCons 3.0.X.
>
> For me this is all about consistency: you can't demand cutting edge
> SCons unless you are prepared to use cutting edge Python.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Russel Winder]

On Fri, 2018-05-25 at 15:57 -0600, Mats Wichmann wrote:
> On 05/25/2018 03:44 PM, Bill Deegan wrote:
> > We need to test every version we say we support.
> > That's the purpose of the CI...
> 
> well, sure.
> 
> but Python itself pretty much only supports the last two 3.x versions
> (there may be some emergency bugfixes later than that, if I recall
> the
> most recent release PEP suggested a 5-year sunset even for that which
> would take 3.5 out through 2019).

Which fits with the statement of no change till at least end of 2018.

> 
> And Jonathon:
> 
> > No way. Distros (e.g. Debian 9) package Python 3.5.
> 
> 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.

Not entirely true, there is 2.7.15, but unless there is a 2.7.16 one
cannot claim it is being supported. PSF have basically returned to the
position that Python 2 has gone end of life.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Russel Winder]

On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
> Pretty certain Gary's with me in saying,
> SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
> releases.
> Most likely through (at least) the end of 2018.

You can add me to agreeing with that.

> I know many who actively participate in SCons community live on the
> leading
> edge of OS and Python releases but many users do not.
> Also, there are still some rough edges to our Python 3 support. Until
> it's
> rock solid (and no one has found an issue for a while), dropping py
> 2.7
> would be unwise.

I see your finger pointing at me. :-)

We have had not dissimilar maintenance debates in the Apache Groovy
community, especially now JDK is updated every 6 months instead of
every 6 years. Clearly there is a need to support people using ancient
three year old systems. Debian Stable and Ubuntu LTS really set the
timescales here, and the Python versions. Except that Travis-CI appears
to think using the most ancient Ubuntu LTS they can is a good thing.

But then come the issues at the heart of the matter: If people are
using three or five year old platforms, will they be using the very
latest version of SCons? If they want the very latest SCons why can't
they install the very latest Python? If they are happy with the three
year old Python will they actually be happy with the three year old
SCons? If a distribution provides Python and SCons why is there any
interest in them updating anything?

Groovy used to have a "we must be totally backward compatible"
obsession that was over the top, especially for me. Over the last year
the policy has changed towards something much better, and which has
allowed Groovy to progress much better in a highly dynamic world.

OK so Java has the big difference that you distribute compiled
artefacts and there are only link time issues, whereas Python is
distributed as source so everything is compile time issues. But the
Groovy team have now begun to accept that "backward compatibility" can
be taken too far. For each major version of Groovy a lower limit is now
set and if people are not prepared to update their Java, then they have
to use the last version of Groovy that works with that version of Java.

Python 2 is the millstone for SCons 3. The question is whether there
will be a 2.7.16 or whether 2.7.15 is really the last version. Also
will an organisation break ranks with PSF policy and pick up Python 2.7
and keep it going? Would that matter for SCons?

I can fully understand sticking with 3.5 at this time, but SCons
versions must be allowed to change the minimum Python version. Should
SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
then people not on Python 3.6 simply stay with SCons 3.0.X.

For me this is all about consistency: you can't demand cutting edge
SCons unless you are prepared to use cutting edge Python.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Gary Oberbrunner]

Pretty certain Gary's with me in saying,
SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
Most likely through (at least) the end of 2018.


Yes, absolutely. SCons is used by lots of people on older legacy systems.
IMHO it is and needs to be a solid, reliable build tool, not (just) a
leading-edge dev tool.

-- Gary


On Fri, Jul 20, 2018 at 11:27 PM Bill Deegan 
wrote:

> Pretty certain Gary's with me in saying,
> SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
> Most likely through (at least) the end of 2018.
>
> I know many who actively participate in SCons community live on the
> leading edge of OS and Python releases but many users do not.
> Also, there are still some rough edges to our Python 3 support. Until it's
> rock solid (and no one has found an issue for a while), dropping py 2.7
> would be unwise.
>
>
> -Bill
> SCons Project Co-Manager.
>
> On Fri, Jul 20, 2018 at 4:11 PM, Jonathon Reinhart <
> jonathon.reinh...@gmail.com> wrote:
>
>> > True but who uses Debian Stable for anything relating to software
>> > development, it is a server distribution.
>>
>> I'm not sure where you got the idea that Debian is a "server
>> distribution". Lots of people use Debian as a desktop OS, and my team
>> uses Debian for software development.
>>
>> I think SCons would be making a serious mistake if it dropped support
>> for Python 3.5. Just because the distro is using an older version of
>> SCons, doesn't mean that SCons shouldn't support the latest version of
>> Python available on the system.
>>
>> This is particularly troublesome for me as I consider putting together
>> a new build image, based on Debian 9, but with latest SCons installed
>> from source.
>>
>> I'm all for cleaning up old cruft, but it seems like removing support
>> for a version of Python that's less than 3 years old seems a bit
>> aggressive.
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Russel Winder]

On Fri, 2018-07-20 at 16:11 -0400, Jonathon Reinhart wrote:
> > True but who uses Debian Stable for anything relating to software
> > development, it is a server distribution.
> 
> I'm not sure where you got the idea that Debian is a "server
> distribution". Lots of people use Debian as a desktop OS, and my team
> uses Debian for software development.

Debian Stable is an excellent server distribution. All the developers I
know that use Debian use Debian Sid for software development. I use
Debian Sid for all my work, though I dual boot Fedora Rawhide for
testing, I see no positive benefit to using Debian Stable as a work
platform for software development.

> I think SCons would be making a serious mistake if it dropped support
> for Python 3.5. Just because the distro is using an older version of
> SCons, doesn't mean that SCons shouldn't support the latest version
> of
> Python available on the system.

I think I agree with this. If we were talking about 3.4, i'd say drop
it. But 3.5 is a reasonable lower limit at the moment. OK it means not
being able to use some good stuff from 3.6 and 3.7 but that is not
possible anyway if running on 2.7 is required, and a lot of the new
stuff in 3.6 and 3.7 is just trendy rubbish that never should have made
it into the distribution – it should have been packages hosted in PyPI.

> This is particularly troublesome for me as I consider putting
> together
> a new build image, based on Debian 9, but with latest SCons installed
> from source.
> 
> I'm all for cleaning up old cruft, but it seems like removing support
> for a version of Python that's less than 3 years old seems a bit
> aggressive.

I agree. In a couple of years when we have 3.8 or 3.9 I'll be all for
dropping 3.5 and 2.7 and refactoring the codebase to 3.6.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev