<div dir="ltr">On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi <span dir="ltr"><<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>></span> wrote:<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We do our best now to backport what is backportable to stable/juno.<br></blockquote><div><br></div><div>This certainly has gotten much better, but I don't think it's 100% there yet either.  It's just a ton of work and we probably need better tooling around this to expect it to be as good as it should be.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FWIW, even without rabbit/kombu topic, master won't work on Juno, there<br>
is plenty of things that are brought in Kilo.<br></blockquote><div><br></div><div>That may be the case in some areas, but we're using it without issues (until now) on Ubuntu with the features we need.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My opinion is we should follow other projects that use stable branches<br>
with doing deprecation for one (or more?) release (currently our master)<br>
and then drop the deprecations after some time.<br>
<br>
So I would propose this policy:<br>
* for new features, patch master with backward compatibility<br></blockquote><div><br></div><div>Agreed, I think some of these might also be candidates for back port if they're new "module features".  For example a new cinder backend that existed in the previous release might get back ported if they're just adding a new class.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* backports relevant patches from master to stable branches (mainly bugs)<br></blockquote><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* in the case of rabbit or any update in OpenStack upstream, update<br>
master without backward compatibility, except if we accept to have a lot<br>
of if/else in our code, and a lot of backwards to support; I'm not in<br>
favor of that.<br></blockquote><div><br></div><div>I think I agree here also.  However, I'd like to see us avoid making breaking changes solely to avoid deprecation warnings until x amount of time after a release comes out.  If we're able to support some level of backwards compatibility, then it also makes upgrading between releases a lot easier.  Upgrading all of your packages, db schemas, etc is a lot less scary and easier to test than upgrading all that + every OpenStack puppet module you use at the same time.</div></div></div></div>