Let's get real about releases

[William Reade]

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.)

> 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.)

> 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.

> 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.

Cheers
William