<div dir="ltr"><div class="gmail_default">The Oslo team is working hard to move code from the incubator into libraries, and that work will speed up during Juno. As part of the planning, we have been developing our deprecation policy for code in the oslo-incubator repository. We recognize that it may take some projects longer than others to adopt the new libraries, but we need to balance the need for long-term support with the amount of effort it requires to maintain multiple copies of the code.</div>
<div class="gmail_default"><br></div><div class="gmail_default">We have, during icehouse, been treating the master branch of oslo-incubator as the "stable" branch for oslo.messaging. In practice, that has meant refusing new features in the incubator copy of the rpc code and requiring bug fixes to land in oslo.messaging first. This policy is described in the wiki (<a href="https://wiki.openstack.org/wiki/Oslo#Graduation">https://wiki.openstack.org/wiki/Oslo#Graduation</a>):</div>
<div class="gmail_default">    </div><div class="gmail_default">    After the first release of the new library, the status of the module(s) should be updated to "Obsolete." During this phase, only critical bug fixes will be allowed in the incubator version of the code. New features and minor bugs should be fixed in the released library, and effort should be spent focusing on having downstream projects consume the library.</div>
<div class="gmail_default"><br></div><div class="gmail_default">    After all integrated projects that use the code are using the library instead of the incubator, the module(s)_ can be deleted from the incubator.</div><div class="gmail_default">
<br></div><div class="gmail_default">We would like to clarify the first part, and add a time limit to the second part:</div><div class="gmail_default">    </div><div class="gmail_default">    After the first release of the new library, the status of the module(s) should be updated to "Obsolete." During this phase, only critical bug fixes will be allowed in the incubator version of the code. All changes should be proposed first to the new library repository, and then bug fixes can be back-ported to the incubator. New features and minor bugs should be fixed in the released library only, and effort should be spent focusing on having downstream projects consume the library.</div>
<div class="gmail_default">    </div><div class="gmail_default">    The incubator version of the code will be supported with critical bug fixes for one full release cycle after the library graduates, and then be deleted. If all integrated projects using the module(s) update to use the library before this time period, the module(s) may be deleted early. Old versions will be maintained in the stable branches of the incubator under the usual long-term deprecation policy.</div>
<div><br></div><div><div class="gmail_default" style="font-size:small">I will update the wiki, but I also wanted to announce the change here on the list so everyone is aware.</div><br></div><div><br></div><div class="gmail_default" style="font-size:small">
Doug</div><div class="gmail_default" style="font-size:small"><br></div></div>