Let's get real about releases

[Clint Byrum]

Hey guys, so as I finish testing in preparation for the final upload
of juju to precise tomorrow, I can't help but wonder if there can be a
better way.

This cycle has been full of stress, ups and downs, and a ton of really
great features have landed.

But along the way, it was more than bumpy. We broke all existing juju
deployments at least twice, and added a few features that have made new
charms unusable on old versions of juju.

All of this was necessary, as juju needs to get to a basic core level
of functionality, and stopping for stabilization or making guarantees
about maintenance would just delay having even the most basic level of
usability implemented.

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.

So, here is the plan I suggest we implement:

* for 6 weeks, feature branches should be landed in trunk with the same
level of review and velocity we've had thus far.
* After this 6 weeks, trunk is frozen for 1 week to allow any minor
fixes and bring documentation of newly landed features up to speed.
* trunk is released, and re-opened for development. This final week
is kept open for critical bug fixes related to the release, but is
effectively open for new feature dev as well.
* whichever release is shipped in Ubuntu, is supported with fixes for
the life of that release of Ubuntu. Ubuntu will in theory do this anyway,
but I'd like to make it formally part of upstream so that juju can have a
micro release exception and keep shipping bug fixes into Ubuntu unimpeded
by the usual cumbersome SRU process.

Since 6 months are actually 26 weeks instead of 24, we will tack on 1
extra week to the first two dev cycles, so it would be 7 full weeks of
open development.

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

I know this is a lot of words, and you may be asking why bother?

I think doing this is important for keeping the high pace of development
up without having the wild thrashing and frequent breakage that we've
seen in the past.

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.

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.

If we can't come to a consensus here on the mailing list, we can have
a session at UDS.

I appreciate feedback from everybody.