The application projects are dropping python 2.6 support during Kilo, and I’ve 
had several people ask recently about what this means for Oslo. Because we 
create libraries that will be used by stable versions of projects that still 
need to run on 2.6, we are going to need to maintain support for 2.6 in Oslo 
until Juno is no longer supported, at least for some of our projects. After 
Juno’s support period ends we can look again at dropping 2.6 support in all of 
the projects.

I think these rules cover all of the cases we have:

1. Any Oslo library in use by an API client that is used by a supported stable 
branch (Icehouse and Juno) needs to keep 2.6 support.

2. If a client library needs a library we graduate from this point forward, we 
will need to ensure that library supports 2.6.

3. Any Oslo library used directly by a supported stable branch of an 
application needs to keep 2.6 support.

4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one of 
the previous rules applies.

5. The stable/icehouse and stable/juno branches of the incubator need to retain 
2.6 support for as long as those versions are supported.

6. The master branch of the incubator needs to retain 2.6 support until we 
graduate all of the modules that will go into libraries used by clients.

A few examples:

- oslo.utils was graduated during Juno and is used by some of the client 
libraries, so it needs to maintain python 2.6 support.

- oslo.config was graduated several releases ago and is used directly by the 
stable branches of the server projects, so it needs to maintain python 2.6 

- oslo.log is being graduated in Kilo and is not yet in use by any projects, so 
it does not need python 2.6 support.

- oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo, but 
both are used by client projects, so they need to keep python 2.6 support. At 
that point we can evaluate the code that remains in the incubator and see if 
we’re ready to turn of 2.6 support there.

Let me know if you have questions about any specific cases not listed in the 


PS - Thanks to fungi and clarkb for helping work out the rules above.
OpenStack-dev mailing list

Reply via email to