[Scons-dev] Undocumented Python 2.6 requirement boost

[anatoly techtonik]

On Wed, Dec 31, 2014 at 2:37 PM, Dirk Baechle <tshortik at gmx.de> wrote:
> Am 28.12.2014 um 11:57 schrieb anatoly techtonik:
>
>> Hi,
>>
>> I've noticed that our README.rst lists Python 2.6
>> as minimum requirement. But:
>>
>>    src/README.txt
>>    src/RELEASE.txt
>>    src/Announce.txt
>>    src/CHANGES.txt
>>
>> All these files doesn't record where did that
>> happened. Moreover Announce.txt says that
>> everything below 2.7 is deprecated.
>>
>> Can we reach some clarity in this mess? =)
>>
>
> the "Announce.txt" for
>
>   RELEASE 2.3.1 - Mon, 02 Mar 2014 13:53:45 -0400
>
> contains the note:
>
> """
>  Please note the following important changes since release 2.2.0:
>
>     -- SUPPORT FOR PYTHON VERSIONS BEFORE 2.7 IS NOW DEPRECATED
>
>        ***IMPORTANT***: This release is the last version of SCons to support
>        Python versions older than 2.7.  This release will warn if you are
>        running on Python 2.6 or older; future releases will probably not
>        work at all, as we are moving toward supporting Python 3.
>        Use --warn=no-python-version to suppress the warning if needed.
>
>     -- A lot of python pre-2.4 compatibility code was removed
>        in this release.  2.4 is the official floor for SCons,
>        but this release will likely enforce it more rigidly.
> """
>
> which properly and clearly starts the deprecation cycle, warning users to
> prepare for the switch to Python 2.7/3.x. In the current state of
> development we try to keep as much of the code 2.6 compatible as long as we
> can, as a convenience for users that are still stuck with older Python
> versions 2.6.x. But when we add new functionality and *have* to use 2.7
> features, we are free to do so. Saying that everything < 2.7 is deprecated
> means (to me) that when suddenly things break for a user under Python 2.6,
> it's not a bug and we're not obliged to make things work again in older
> versions. I really fail to see a mess here...

Out "properly and clearly" practice is failing. How about adding this info
into the CHANGES.txt and make it a primary source to track development
including version changes. I'd also like to see the link to discussion and
summary of the arguments in commit message.

Also, please tie the deprecation scheme with deprecation plan with
pinned SCons version numbers or it becomes too verbose and vague
from the outside.

"...we're not obliged to make things work again..." - I don't want to be a
support superhero either, but if SCons breaks this stuff - it will help a
lot of people if there is an explanation *why* for every breakage, so that
people who need to get SCons running on Python 2.6 again, could
make their own choice whatever they need to move their infrastructure
to 2.7.
-- 
anatoly t.