On 21 November 2013 07:14, Mark Washenberger <mark.washenber...@markwash.net> wrote: > Hi folks, > > The project python-glanceclient is getting close to needing a major release > in order to finally remove some long-deprecated features, and to make some > minor adjustments that are technically backwards-incompatible. > > Normally, our release process works great. When we cut a release (say > 1.0.0), if we realize it doesn't contain a feature we need, we can just add > the feature and release a new minor version (say 1.1.0). However, when it > comes to cutting out the fat for a major release, if we find a feature that > we failed to remove before releasing 1.0.0, we're basically screwed. We have > to keep that feature around until we feel like releasing 2.0.0. > > In order to mitigate that risk, I think it would make a lot of sense to have > a place to stage and carefully consider all the breaking changes we want to > make. I also would like to have that place be somewhere in Gerrit so that it > fits in with our current submission and review process. But if that place is > the 'master' branch and we take a long time, then we can't really release > any bug fixes to the v0 series in the meantime. > > I can think of a few workarounds, but they all seem kinda bad. For example, > we could put all the breaking changes together in one commit, or we could do > all this prep in github. > > My question is, is there a correct way to stage breaking changes in Gerrit? > Has some other team already dealt with this problem?
Why not just propose them to Gerrit? Get a set of reviews +2 +2 but not APRV, and once you're satisfied you have everything, approve them then release. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev