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 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  
To unsubscribe or change options:

Reply via email to