[gentoo-python] Timeframe for supporting Python versions

[gentoo-python] Timeframe for supporting Python versions

[Kacper Kowalik]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

Hi all,
I'd like to bring a discussion that was started over irc for broader
audience. Namely:
1) how long are we supposed to keep old version of Python in Portage?
2) how many version should we actively maintained?

What came up:
 * python2.5 is no longer supported upstream since May 2011 and is first
candidate for purging
 * python3.2 supersedes python3.1 without introducing any obvious
incompatibilities (at least that's what they claim here[1])

What's worth noting is that upstream itself will provide/provides new
release cycle, introducing LTS version of python[2]. First proposal by
neurogeek, is that following pep0407 we should obsolete versions of
python 6 months after upstream ceases to support them. (+1 from me on that)

Cheers
Kacper

[1] http://www.python.org/dev/peps/pep-3003/
[2] http://www.python.org/dev/peps/pep-0407/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-python] Timeframe for supporting Python versions

[Dirkjan Ochtman]

On Mon, Apr 30, 2012 at 20:17, Kacper Kowalik <xarthisius@gentoo.org> wrote:
> 1) how long are we supposed to keep old version of Python in Portage?
> 2) how many version should we actively maintained?

I'm not sure we need hard rules here. IMO the current approach (i.e.
just talking about it and dropping as we decide it makes sense) is
just fine. In particular, some version bumps are just harder than
others, and adoption of new versions is always different (i.e. for 3.x
and 2.x versions is obviously a very different story right now). From
the other side (for example, in Mercurial depends), it also depends
how big of a boon new features are.

So let's just decide on a case-by-case when we deprecate a version? As
for 2.5, are we seeing increased incompatibility yet? Any recent
examples? I think 2.5 is close to deprecation, but I'm personally not
getting the impression it's getting to be a big PITA just yet.

Cheers,

Dirkjan

Re: [gentoo-python] Timeframe for supporting Python versions

[Kacper Kowalik]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On 30.04.2012 22:13, Dirkjan Ochtman wrote:
> On Mon, Apr 30, 2012 at 20:17, Kacper Kowalik <xarthisius@gentoo.org> wrote:
>> 1) how long are we supposed to keep old version of Python in Portage?
>> 2) how many version should we actively maintained?
> 
> I'm not sure we need hard rules here. IMO the current approach (i.e.
> just talking about it and dropping as we decide it makes sense) is
> just fine. In particular, some version bumps are just harder than
> others, and adoption of new versions is always different (i.e. for 3.x
> and 2.x versions is obviously a very different story right now). From
> the other side (for example, in Mercurial depends), it also depends
> how big of a boon new features are.
> 
> So let's just decide on a case-by-case when we deprecate a version? As
> for 2.5, are we seeing increased incompatibility yet? Any recent
> examples? I think 2.5 is close to deprecation, but I'm personally not
> getting the impression it's getting to be a big PITA just yet.

10% of packages that restrict Python abi in any way, restrict 2.5 (I've
grepped for "\(2.\[45\]\|2.5\)") That's the only statistics I could
think of.

I'm not aware of any security bugs related to 2.5 branch

Cheers,
Kacper


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-python] Timeframe for supporting Python versions

[Johan Bergström]

Hey, 


On Tuesday, 1 May 2012 at 7:01 AM, Kacper Kowalik wrote:

> On 30.04.2012 22:13, Dirkjan Ochtman wrote:
> > On Mon, Apr 30, 2012 at 20:17, Kacper Kowalik <xarthisius@gentoo.org (mailto:xarthisius@gentoo.org)> wrote:
> > > 1) how long are we supposed to keep old version of Python in Portage?
> > > 2) how many version should we actively maintained?
> > 
> > 
> > 
> > I'm not sure we need hard rules here. IMO the current approach (i.e.
> > just talking about it and dropping as we decide it makes sense) is
> > just fine. In particular, some version bumps are just harder than
> > others, and adoption of new versions is always different (i.e. for 3.x
> > and 2.x versions is obviously a very different story right now). From
> > the other side (for example, in Mercurial depends), it also depends
> > how big of a boon new features are.
> > 
> > So let's just decide on a case-by-case when we deprecate a version? As
> > for 2.5, are we seeing increased incompatibility yet? Any recent
> > examples? I think 2.5 is close to deprecation, but I'm personally not
> > getting the impression it's getting to be a big PITA just yet.
> 
> 
> 
> 10% of packages that restrict Python abi in any way, restrict 2.5 (I've
> grepped for "\(2.\[45\]\|2.5\)") That's the only statistics I could
> think of.
> 
> I'm not aware of any security bugs related to 2.5 branch
I raised the same question a couple of months ago, just to get a discussion going on what we consider "deprecated". Python 2.5 is one of those versions that actually work pretty well, so it will probably be here for a long time. A perhaps better way of looking at this is how many packages that depend explicitly on 2.5 to work and understand why upstream stays there.

For me as a fellow package bumper, I'd say that 2.5 is still good to go.
> 
> Cheers,
> Kacper

Thanks, 
Johan

Re: [gentoo-python] Timeframe for supporting Python versions

[Jesus Rivero (Neurogeek)]

Hi guys,

On Mon, Apr 30, 2012 at 5:07 PM, Johan Bergström <bugs@bergstroem.nu> wrote:
> Hey,
>
>
> On Tuesday, 1 May 2012 at 7:01 AM, Kacper Kowalik wrote:
>
>> On 30.04.2012 22:13, Dirkjan Ochtman wrote:
>> > On Mon, Apr 30, 2012 at 20:17, Kacper Kowalik <xarthisius@gentoo.org (mailto:xarthisius@gentoo.org)> wrote:
>> > > 1) how long are we supposed to keep old version of Python in Portage?
>> > > 2) how many version should we actively maintained?
>> >
>> >
>> >
>> > I'm not sure we need hard rules here. IMO the current approach (i.e.
>> > just talking about it and dropping as we decide it makes sense) is
>> > just fine. In particular, some version bumps are just harder than
>> > others, and adoption of new versions is always different (i.e. for 3.x
>> > and 2.x versions is obviously a very different story right now). From
>> > the other side (for example, in Mercurial depends), it also depends
>> > how big of a boon new features are.
>> >
>> > So let's just decide on a case-by-case when we deprecate a version? As
>> > for 2.5, are we seeing increased incompatibility yet? Any recent
>> > examples? I think 2.5 is close to deprecation, but I'm personally not
>> > getting the impression it's getting to be a big PITA just yet.

I wasn't trying to impose hard rules either, just to have rules that
would give us a notion on when to start considering punting an older
version. I'm not really sure about this, but I think fixes aren't
being backported to Python2.5 anymore on upstream, and Python2.6 is
now the LTS version. If thats the case, the burden on fixing important
bugs in unsupported versions will fall on us.

Also, Python2.4 differs from Python2.5 way more than Python2.5 differs
from Python2.6, and Python2.6 is pretty stable nowadays. So, I don't
think we will have a problem in that front if we decide to drop 2.5.

So, no hard rules, but a general "agreement" to start discussing Pros
and Cons after certain "events".

BTW, Twisted is dropping support for Python2.5 after their 12.1
release, which will be soon.

Cheers,

>>
>>
>>
>> 10% of packages that restrict Python abi in any way, restrict 2.5 (I've
>> grepped for "\(2.\[45\]\|2.5\)") That's the only statistics I could
>> think of.
>>
>> I'm not aware of any security bugs related to 2.5 branch
> I raised the same question a couple of months ago, just to get a discussion going on what we consider "deprecated". Python 2.5 is one of those versions that actually work pretty well, so it will probably be here for a long time. A perhaps better way of looking at this is how many packages that depend explicitly on 2.5 to work and understand why upstream stays there.
>
> For me as a fellow package bumper, I'd say that 2.5 is still good to go.
>>
>> Cheers,
>> Kacper
>
> Thanks,
> Johan
>
>



-- 
Jesus Rivero (Neurogeek)
Gentoo Developer