increasing the python requirement

[Martin Pool]

On 5 January 2011 05:33, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
>>>>>> Jelmer Vernooij <jelmer at vernstok.nl> writes:
>
>    > If bzr 2.4 introduced any format changes then not supporting Python 2.4
>    > would be a much bigger deal IMO, because users would have to upgrade to
>    > 2.4 to interact with repositories in the newer format.

That's a very good point.

> Not anymore since you mentioned it :)
>
> Iff we introduced a new format, we'll also have to support it for
> python-2.4 [1]

We could adopt that rule, though it's not one we've had to date.

In the case of 2a, we did quite a lot of internal restructuring so
that bzr could take advantage of operations that were fast in the new
format.  If we do a new major format (as opposed to just adding some
minor options) then that would be quite a large patch to backport.

Taking such a large patch into a stable series seems to me to run a
real risk of breaking plugins or introducing new bugs, which are
things we really want to avoid in the stable series.  We could split
off a new "2.2 with format 3a support" branch, but that has a cost
too.

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

It's possible that would seem like an unacceptable amount of churn for
people who are running say 2.2 and who want to get only safe bug
fixes.

We could also do a kind of backport along a different vector by taking
say bzr 2.5.0 and undoing any python>2.4 specific work.

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.

-- 
Martin