Open Stack

On Wed, 2013-11-20 at 15:17 -0800, Clint Byrum 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.
> 
> 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.

Sorry, completely disagree with this. This is the point of having a
major version number in client libraries, when you need to do backward
incompatible changes then you bump the major version. You can continue
to develop the 0.x and 1.x series in parallel for some amount of time
and that's common.

If your application doesn't work with the 1.x series then you modify
your requirements to indicate this.

If this is going to be a problem in openstack then we need to figure out
a way of dealing with it because the client libraries are in general a
mess and i know that at least keystone is not far off needing to make
backward incompatible changes to start to clean it up.

Sorry about your disclaimer :)

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev