On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi <emil...@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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
