increasing the python requirement

[Martin Pool]

On 5 January 2011 10:44, Martin Pool <mbp at canonical.com> wrote:
> Alternatively we could try to add "slow but safe" support for the new
> format to the old series, in a way that doesn't change APIs and that
> changes the code as little as possible, but this

.... is a bit like writing the format over again a second time.  Or
perhaps the core storage objects (that were previously not referenced)
could use the same code as in trunk, but you would need different glue
to connect them to the Repository format, etc.  Because you would be
writing a fair bit of new code specifically to adapt the new format to
the old structure, there may be bugs in that code that aren't caught
by testing trunk and again that's something we want to avoid in stable
series.

Of course it depends quite a lot on just what changes are introduced
by the new format.

I think, if you were going to deploy this, it might make sense to put
the new format into a plugin that works with the old format, which
would have no risk of destabilizing people who aren't using that
plugin.  But the issue that it's extra work still remains, so

> Any of these seem like a high price to pay if the benefit is just
> getting to use some nicer python2.5/2.6 source constructs.

Based on the thread to date it seems like the best course now is to
keep supporting python2.4 unless there's a stronger reason than just
wanting to use new 2.5/2.6 syntax.  Getting a single codebase that
also works on 3.x might be such a reason, if it turns out that is
actually necessary.

I do remember sometimes getting test failures because I forgot about
something that either doesn't exist or is buggy in python2.4.  But for
me it's not very frequent and not creating so much pain it would be
worth causing trouble for people using old distros, or the hassle of
backporting new formats.

-- 
Martin