[openstack-dev] Python and OS version support
Monty Taylor
mordred at inaugust.com
Mon Nov 26 16:40:15 UTC 2012
Hey all!
I started a discussion during a TC meeting a little while ago that needs
more general input and feedback. The question at hand is "what versions
of python and what versions of what distros do we care about as a project?"
First of all, this isn't a discussion about what CI will test or what
we'll use for gating. It's more of a conversation about what language
and OS assumptions developers can make when they are writing code, so
that design and review choices can be made.
To put it more bluntly, if someone files a bug or a code review comment
that says:
"Blah doesn't work in python X"
When can we respond "not a bug/won't fix" with a clear conscience?
When we first started the project, we said out loud that development was
always focused on the current release of Ubuntu and that's it. We picked
that because doing _development_ targeting a bazillion distro options at
the same time gets hairy quickly, and I think the clarity served has us
well. But I'm pretty sure things have changed since then - latest Ubuntu
does not come with python 2.6, for instance, but we still seem to care
about it.
With that background, I'd like to start things off by proposing the
following:
a) We continue to focus development efforts of master on the latest
release of Ubuntu with python libraries coming from PyPI.
b) We don't introduce things into master that would be unworkable on
either latest Ubuntu LTS or latest RHEL.
Logistically, because of our development focus on pypi modules in
virtualenvs, this doesn't affect much for developers outside of base
python versions and a few things that can't go in a virtualenv like
libvirt or the kernel. Since RedHat and Canonical have both committed to
maintaining special backport repos for those things for users of RHEL
and Ubuntu LTS, I don't think in practice it's going to have much of a
noticeable impact.
Except where it comes to base python versions.
If we take the above to be correct, it has the following effect:
- We need to care about python 2.6 compatibility until such a time as
there is a RHEL that has 2.7 in it.
- 2.7 should be our current dev focus, so if possible we should code to
2.7 libs and then use backport packages like unittest2 to make 2.6 happy.
- We can't REALLY start thinking about Python3 in earnest until a RHEL
release comes out with python 2.7, because 2.7/3.3 are needed for
source-code compatible code
Net result - pretty much exactly what we're doing today, it just gets it
down on paper a little better.
Thoughts? Disagreements?
Monty
More information about the OpenStack-dev
mailing list