Open Stack

On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi <emilien at redhat.com> wrote:

> We do our best now to backport what is backportable to stable/juno.
>

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.


> FWIW, even without rabbit/kombu topic, master won't work on Juno, there
> is plenty of things that are brought in Kilo.
>

That may be the case in some areas, but we're using it without issues
(until now) on Ubuntu with the features we need.


> My opinion is we should follow other projects that use stable branches
> with doing deprecation for one (or more?) release (currently our master)
> and then drop the deprecations after some time.
>
> So I would propose this policy:
> * for new features, patch master with backward compatibility
>

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.


> * backports relevant patches from master to stable branches (mainly bugs)
>
Agreed.


> * in the case of rabbit or any update in OpenStack upstream, update
> master without backward compatibility, except if we accept to have a lot
> of if/else in our code, and a lot of backwards to support; I'm not in
> favor of that.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150416/b0fccae9/attachment.html>