Thomas A. F. Thorne:
> Dropping Python 2 Support
> (or more specifically moving up to python2.7 from python2.4 on a
> maintenance branch and dropping python3 support from master)
The actual suggestion was to drop python _2.2_, but leave the rest.
There was nothing on the maintenance branch that required newer...
> Having looked into starting a 3.2 release or 3.2_maintenance branch I
> stumbled into the https://github.com/distcc/distcc/pull/177 request.
> Under that request the creation of the 3.2 maintenance branch is
> suggested and it is proposed that said branch will be used to maintain
> some support for Python2.7 for as long as it seems necessary.
The half-way option (drop the really old stuff, keep the default
system /usr version of python on enterprise linux releases) was in:
The master branch can stay as it is. That is, only support python3
but not any variant of python2 (2.7). Mostly for "non-pump" mode.
> The main work would continue on master, with the creation of a 3.3.#
> release in the near future. The master branch (and therefore the 3.3
> releases onwards) would require python3.
Sure, I have no problem with that. I'm not sure _what_ development that
was planned on "master" (that required python3), but it's there already.
I also suggest getting off the "3.2rc1" track, and releasing real 3.#.#
Is there anything on master that needs a 3.3 release ? The swift stuff ?
i.e. supposedly you would also do a maintenance branch for 3.3 as well.
(if you decide to fork it off from master, that is). And then merge.
Something like a road map would be nice, to see what the difference is.
Maybe 3.2 should have been forked even earlier in history, I dunno...
But it would be nice to do another "stable" release after distcc-3.1.
Which is from 2008 already.
Many stay off the distcc-3.2rc1, because of the silly release suffix.
And that was back in 2011 ?
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options: