<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 20, 2013 at 3:17 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Mark Washenberger's message of 2013-11-20 10:14:42 -0800:<br>
<div><div class="h5">> Hi folks,<br>
><br>
> The project python-glanceclient is getting close to needing a major release<br>
> in order to finally remove some long-deprecated features, and to make some<br>
> minor adjustments that are technically backwards-incompatible.<br>
><br>
> Normally, our release process works great. When we cut a release (say<br>
> 1.0.0), if we realize it doesn't contain a feature we need, we can just add<br>
> the feature and release a new minor version (say 1.1.0). However, when it<br>
> comes to cutting out the fat for a major release, if we find a feature that<br>
> we failed to remove before releasing 1.0.0, we're basically screwed. We<br>
> have to keep that feature around until we feel like releasing 2.0.0.<br>
><br>
> In order to mitigate that risk, I think it would make a lot of sense to<br>
> have a place to stage and carefully consider all the breaking changes we<br>
> want to make. I also would like to have that place be somewhere in Gerrit<br>
> so that it fits in with our current submission and review process. But if<br>
> that place is the 'master' branch and we take a long time, then we can't<br>
> really release any bug fixes to the v0 series in the meantime.<br>
><br>
> I can think of a few workarounds, but they all seem kinda bad. For example,<br>
> we could put all the breaking changes together in one commit, or we could<br>
> do all this prep in github.<br>
><br>
> My question is, is there a correct way to stage breaking changes in Gerrit?<br>
> Has some other team already dealt with this problem?<br>
><br>
> DISCLAIMER:<br>
> For the purposes of this discussion, it will be utterly unproductive to<br>
> discuss the relative merits of backwards-breaking changes. Rather let's<br>
> assume that all breaking changes that would eventually land in the next<br>
> major release are necessary and have been properly communicated well in<br>
> advance. If a given breaking change is *not* proper, well that's the kind<br>
> of thing I want to catch in gerrit reviews in the staging area!<br>
<br>
</div></div>I understand what you're trying to do with this disclaimer. The message<br>
above just _screams_ for this discussion, so why not cut it off at the<br>
pass? However, glanceclient being a library, not discussing the fact<br>
that you're breaking an established API is like not discussing ice at<br>
the north pole.<br></blockquote><div><br></div><div>It is both a CLI and a library. I think different considerations might be more relevant for those different areas. But this point leads to a much larger discussion of what standards we should enforce for major revisions, which we should probably defer for just a moment. I hope the outcome of discussing my main point will be a space where we can flesh out such standards with real world examples.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you want to be able to change interfaces without sending a missile<br>
up the tail pipe of every project who depends on your code, call it<br>
glanceclient2. That solves all of your stated problems from above. You can<br>
still deprecate glanceclient and stop maintaining it after some overlap<br>
time. And if users hate glanceclient2, then they can keep glanceclient<br>
alive with all of its warts.<br></blockquote><div><br></div><div>While I think glanceclient2 is an interesting suggestion for really large, sweeping changes, I don't think we are anywhere near that point.</div><div><br>
</div><div>Overall, I think you are unintentionally mischaracterizing the nature of the breaking changes that are being considered--making them seem several orders of magnitude greater and more disruptive than they actually are. For folks who believe that under very well-defined and conservative circumstances it is okay to make a breaking change in a major release, this mischaracterization is going to be really confusing.</div>
<div><br></div><div>I guess if we still want to talk about when, if ever, to release a major version of a client, maybe we could take it to another thread? The proposal to disallow major revisions of OpenStack clients under all normal circumstances seems like great TC fodder in any case, especially now that I'm only a spectator.</div>
<div><br></div><div><3,</div><div>markwash</div></div></div></div>