Let's get real about releases

[Clint Byrum]

Excerpts from William Reade's message of Tue Apr 17 01:25:01 -0700 2012:
> On Mon, 2012-04-16 at 22:50 -0700, Clint Byrum wrote:
> > However, I think juju is just about there, and its time to think about
> > putting in some formal release process so we can keep the high speed of
> > feature development without driving our users away.
> 
> +many. This is the first project I've worked on in which user-facing
> consequences effectively apply per-commit rather than per-release, and I
> think this process (or lack thereof) harms development as well as the
> user experience.
> 
> > So, here is the plan I suggest we implement:
> >...
> > Backward incompatible changes can still land at any time, but these need
> > to bump the "series" in launchpad. Each series will have its own PPA
> > in juju so that users can choose a series and stay on it without fear
> > of backward incompatible changes breaking them.
> 
> This is entirely a good thing, but IMO it's only a stopgap measure: it
> wouldn't be necessary if we had a viable story for code upgrades and ZK
> migrations on running deployments, which is surely fiddly but surely not
> impossible. (So: I'm not arguing against this approach, but I am arguing
> that we should take measures to make it obsolete.)
> 

Indeed, we need to have a good discussion around "environment
stability". I'd like to make it a high priority for near term feature
development. I do have to wonder if putting a more simplified REST API
between the clients and Zookeeper will make this a bit easier, since
the smarts would be moved away from the client.

> > This aligns juju with Ubuntu's release cycle quite well. The cycle
> > should be offset back 2 weeks from Ubuntu's. This will allow developers
> > to make choices about what features to land in each release given the
> > state of juju in Ubuntu. The first two cycles will easily land within
> > FeatureFreeze of the release of Ubuntu, which is usually around week 18
> > (and this cycle will be offset 2 weeks earlier than Ubuntu releases).
> > 
> > That third cycle should not really be any different. In reality, we will
> > want to have feature freeze exceptions sometimes, and ship the latest
> > juju into Ubuntu. The cycle will still keep us just within FinalFreeze.
> 
> Very nice. Had we had it this (ubuntu) cycle, the close of the second
> (juju) cycle would have been a really valuable wakeup call for everyone,
> and would have let us distribute the stress of the last month much more
> sensibly...
> 
> > I know this is a lot of words, and you may be asking why bother?
> 
> I'm certainly not asking that myself, and I very much appreciate the
> words and the thought that's gone into them :). 
> 
> > I'd also like to use semantic versioning in this process. As a user, I
> > always appreciate the coded information in a simple version number. 1.0.1
> > means a lot more than "galapagos" or "bzr554". Without a clear release
> > process, I think its harder to use semantic versioning and thus harder
> > for users to know what it is they're getting.
> 
> I'm not clear how the series-bumping interacts with the version
> numbering. Are you suggesting a minor version bump per series bump?
> (Just asking for clarification.)
> 

Minor version yes. In my head, the python version is "version 0". So the
first release of the golang rewrite would be 1.0.0. The next breaking
change would be 1.1.0. The next big paradigm shift, be it another rewrite
or a new way of thinking about charms/deployments/etc. would be 2.0.0. If
I had to make a prediction, I'd say juju handling storage would be a
good place to bump the major version.

> > If this sounds good, we would start the first release cycle immediately. I
> > understand that the python version will not see any features, but we
> > still plan to fix bugs and I'd like to consider making a "release" with
> > the security ACL work that Kapil did into a PPA. Meanwhile go can keep
> > pushing forward until feature parity is reached and then we can move to
> > this release process with go.
> 
> I think the go plan needs a little bit more thought -- there's an
> inflection point somewhere where (I presume) we want people to start
> trying to use the go version even slightly before feature parity -- and
> that is the point at which we need this process in place. With 12.10 as
> a target, I think we should be aiming to close out the first such go
> cycle at the same time as the second such python cycle.
> 

Indeed. I leave it to the team doing the development as to when that
point is reached. I'd suggest calling that point 1.0.0, even with all
the fanfaire that 1.0 means to some people, to me it means "the first
unfinished version of the golang rewrite". Another idea is to just call it
"whatever python is at +1" and fully deprecate python at that point.

> > I appreciate feedback from everybody.
> 
> Thank you for putting this together; my own thinking hadn't really
> progressed beyond "gaaah, we need a proper release process, gibber
> gibber". Unless anyone sees any showstoppers, I feel that we should
> adopt this approach as soon as possible and iron out any potential
> wrinkles as we go.

Indeed, keeping it short means we can chuck the whole thing in the river
in just two short months if it doesn't work out.