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. Doug PS - Thanks to fungi and clarkb for helping work out the rules above. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
