On 10/22/2014 08:15 PM, Doug Hellmann wrote:
> 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 
> support.
> - 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 
> examples.

The rules look ok to me but I'm a bit worried that we might miss
something in the process due to all these rules being in place. Would it
be simpler to just say we'll keep py2.6 support in oslo for Kilo and
drop it in Igloo (or L?) ?

Once Igloo development begins, Kilo will be stable (without py2.6
support except for Oslo) and Juno will be in security maintenance (with
py2.6 support).

I guess the TL;DR of what I'm proposing is to keep 2.6 support in oslo
until we move the rest of the projects just to keep the process simpler.
Probably longer but hopefully simpler.

I'm sure I'm missing something so please, correct me here.

Flavio Percoco

OpenStack-dev mailing list

Reply via email to