On 02/12/13 09:40 -0500, Doug Hellmann wrote:
On Mon, Dec 2, 2013 at 9:25 AM, Flavio Percoco <[email protected]> wrote: On 02/12/13 09:06 -0500, Russell Bryant wrote: On 12/02/2013 08:53 AM, Doug Hellmann wrote: So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained -> Status: Graduating (short term) -> Code removed from oslo-incubator once library is released We should make the module print a deprecation warning which would be more like a 'transition' warning. So that people know the module is being moved to it's own package. I thought about that, too. We could do it, but it feels like code churn. I would rather spend the effort on updating projects to have the libraries adopted.
I was thinking more about updating the oslo module / package without updating them in every OS project. If people syncs the oslo-incubator code, they'll pull the warning in as well.
2) An API being replaced with a better one, like rpc being replaced by
oslo.messaging
Status: Maintained
-> Status: Obsolete (once an RC of a replacement lib has been
released)
-> Code removed from oslo-incubator once all integrated projects have
been migrated off of the obsolete code
We've a deprecated package in oslo-incubator. It may complicate things
a bit but, moving obsolete packages there may make sense. I'd also
update the module - or package - and make it print a deprecation
warning.
The deprecated package is for modules we are no longer maintaining but for
which there is not a direct replacement. Right now that only applies to the
wsgi module, since Pecan isn't an Oslo library.
Makes sense! FF -- @flaper87 Flavio Percoco
pgp3v0KVtLPd0.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
