Open Stack

On Wed, Nov 20, 2013 at 3:17 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Mark Washenberger's message of 2013-11-20 10:14:42 -0800:
> > 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?
> >
> > DISCLAIMER:
> > For the purposes of this discussion, it will be utterly unproductive to
> > discuss the relative merits of backwards-breaking changes. Rather let's
> > assume that all breaking changes that would eventually land in the next
> > major release are necessary and have been properly communicated well in
> > advance. If a given breaking change is *not* proper, well that's the kind
> > of thing I want to catch in gerrit reviews in the staging area!
>
> I understand what you're trying to do with this disclaimer. The message
> above just _screams_ for this discussion, so why not cut it off at the
> pass? However, glanceclient being a library, not discussing the fact
> that you're breaking an established API is like not discussing ice at
> the north pole.
>

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.


>
> If you want to be able to change interfaces without sending a missile
> up the tail pipe of every project who depends on your code, call it
> glanceclient2. That solves all of your stated problems from above. You can
> still deprecate glanceclient and stop maintaining it after some overlap
> time. And if users hate glanceclient2, then they can keep glanceclient
> alive with all of its warts.
>

While I think glanceclient2 is an interesting suggestion for really large,
sweeping changes, I don't think we are anywhere near that point.

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.

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.

<3,
markwash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/204314f1/attachment.html>