Minimum Python Version for Bitten

[John Hampton]

All,

Currently bitten should work with all versions of Python >=2.3. I'm
working on #208 [1] and currently the patch requires the use of
cookielib. cookielib was added in Python 2.4, so we'd have to drop 2.3
support.

With RHEL now shipping Python 2.4 and the current Trac trunk requiring
2.4, is it reasonable to drop 2.3 support in Bitten?

What says everyone?

-John

[1] http://bitten.edgewall.org/ticket/208

[Christopher Lenz]

On 01.08.2009, at 21:56, John Hampton wrote:
> Currently bitten should work with all versions of Python >=2.3. I'm
> working on #208 [1] and currently the patch requires the use of
> cookielib. cookielib was added in Python 2.4, so we'd have to drop
> 2.3
> support.
>
> With RHEL now shipping Python 2.4 and the current Trac trunk requiring
> 2.4, is it reasonable to drop 2.3 support in Bitten?
>
> What says everyone?

I think it's about time to drop the 2.3 support. The only reason I can
think of why someone would want to work with Bitten on 2.3 is to build/
test a Python package on 2.3. You should be able to still do that by
explicitly specifying the Python interpreter in the slave config or
recipe (although if you're using the Bitten test-runner thing you may
need to resort to some trickery to get it working).

So, let's move on ot 2.4 IMHO. Especially if it makes continued
development significantly easier (as is the case for the cookie and
subprocess stuff).

Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/

[osimons]

On Aug 5, 6:47 pm, Christopher Lenz <cml...@gmx.de> wrote:
> On 01.08.2009, at 21:56, John Hampton wrote:
>
> > Currently bitten should work with all versions of Python >=2.3. I'm
> > working on #208 [1] and currently the patch requires the use of
> > cookielib. cookielib was added in Python 2.4, so we'd have to drop
> > 2.3
> > support.
>

> So, let's move on ot 2.4 IMHO. Especially if it makes continued
> development significantly easier (as is the case for the cookie and
> subprocess stuff).
>

Just note that all the 2.4 stuff we are patching and working on are
only intended to be executed on the slave (but will of course tie in
with tests and stuff). David's work on splitting slave and master also
affects this, and of course the nice thing about keeping 2.3 for
master (trac plugin) is that Trac 0.11.x will remain 2.3 compatible
(but increased to 2.4 for trunk/0.12). From the Trac project I see
that many still run Trac on 2.3 - any incompatible change is quickly
followed by a ticket. I'd have no problem with trying to keeping
master 2.3 compatible, but recommending or requiring 2.4 for slaves
("recommending" as in "it will work, but not all features may be
enabled or work optimally" - "require" as in code in setup.py that
won't allow install on less than 2.4).

Anyway, it has been a long time since I've run anything on 2.3 so it
is getting harder and harder to support... 2.4 is inevitable at some
stage, so I suppose the best option is to drop it for 0.6 - if not we
really would need to wait until some illusive 0.7 miletone.

All in all, +1 for dropping - if nothing else because it just makes
life easier :-)

:::simon

https://www.coderesort.com

[John Hampton]

osimons wrote:
> Anyway, it has been a long time since I've run anything on 2.3 so it
> is getting harder and harder to support... 2.4 is inevitable at some
> stage, so I suppose the best option is to drop it for 0.6 - if not we
> really would need to wait until some illusive 0.7 miletone.
>
> All in all, +1 for dropping - if nothing else because it just makes
> life easier :-)

+1 here also. It'll make our life easier, and really, everyone *should*
upgrade their Python to something > 2.3

-John