Open Stack

On 21 November 2013 07:14, Mark Washenberger
<mark.washenberger at 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud