On Oct 23, 2014, at 2:56 AM, Flavio Percoco <fla...@redhat.com> wrote:

> 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?) ?

I think we have to actually wait for M, don’t we (K & L represents 1 year where 
J is supported, M is the first release where J is not supported and 2.6 can be 
fully dropped).

But to your point of keeping it simple and saying we support 2.6 in all of Oslo 
until no stable branches use it, that could work. I think in practice we’re not 
in any hurry to drop the 2.6 tests from existing Oslo libs, and we just won’t 
add them to new ones, which gives us basically the same result.


> 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
> -- 
> @flaper87
> Flavio Percoco
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to