On 10/23/2014 08:56 AM, Flavio Percoco 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?) ? > > 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).
OMFG, did I really say Igloo? I should really consider taking a break. Anyway, just read Igloo as the L release. Seriously, WTF? Flavio > > 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
