On 04/16/2015 02:15 PM, Clayton O'Neill wrote: > On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi <[email protected] > <mailto:[email protected]>> 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. >
A solution could be to add a tag in commits that can be backported? Something like: backport-juno backport-icehouse or just: backport-icehouse And the patch once merged would create the backport auto-magically with a bot ? We would have to add a rule in our policy, to ensure a patch has the tag if needed (core-reviewers will have to take care to see if the tag deserves to be here or not). This is a proposal, it could be wrong at all. > * 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. Well, we also rely on OpenStack upstream (oslo, etc), that use to change configuration parameters. But I agree with you, we should more take care of this kind of changes. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
