Let's get real about releases

[Clint Byrum]

Excerpts from Robbie Williamson's message of Tue Apr 17 08:20:53 -0700 2012:
> Why not follow the approach the MAAS dev team[1] has?  They have 3 PPAs:
>  * Daily - Daily build of trunk
>  * Testing - Users who want to *test* new features
>  * Stable - Users who want to *use* new features
> Then we'd *only* sync in Ubuntu from Stable.
> 

This is a strong system and certainly might work to curtail the "trunk
broke everything" pain.

However, MaaS is not a distributed system really. It has a single API
endpoint, and so a single MaaS deployment controls its own fate, and
owns its database schema and components. There are no distributed pieces
that are not controlled by strong API's like the postgres protocol or
the cobbler API. You can upgrade the maas server at your leisure.

Juju has clients, agents, and a zookeeper tree, all of which can
suffer from version skew of the others bits. If more stringent checks
are put on the API's that are in use between juju components, I think
juju development will slow down. We should also implement the binary
freezing that I recommended last month[1], but that won't save users
from something that is designed *to break that*.

What I'm suggesting is a very similar number of PPA's in fact.

If I overlay the last 10 or so months of juju development with this
process and a version of 0.1.0, it would go something like this:

June - 0.2.0 config settings and expose/unexpose land, breaks Zookeeper for existing deployments.
Aug  - 0.2.1 orchestra lands, no real breakage
Oct  - 0.3.0 renamed to juju, rewrite or orchestra, several minor backward breaks -> Ubuntu 11.10
Dec  - 0.3.1 Minor enhancements and fixes, no breakage
Feb  - 0.4.0 Reboot code breaks all deployments because agents now require new args
Apr  - 0.5.0 Constraints breaks everything. -> Ubuntu 12.04

So, in this case, we'd have ended up with 4 series branches and 4 PPA's:

ppa:juju/0.2 -> lp:juju/0.2
ppa:juju/0.3 -> lp:juju/0.3
ppa:juju/0.4 -> lp:juju/0.4
ppa:juju/0.5 -> lp:juju/0.5

This would have been silly, but thats because we were making breaking
changes in order to meet deadlines and without any sort of plan. If there
were a release process in place, we could have consolidated some of the
breaking changes by just delaying them a bit.  In particular, 0.4 and
0.5 probably didn't need to be separate releases. The reboot code could
have been kept out of trunk for 1 extra week, and there would have been
a 0.3.2 then, and the next release would have been 0.4.0.

Also as of the 11.10 release of Ubuntu, I think we'd just delete the 0.2
PPA, and likewise with 12.04 we'd delete the 0.4 PPA, in acknowledgement
of the fact that they were just interim releases. Perhaps if we see
very little usage of these PPA's, we would stop creating them for the
interim releases.

There's another benefit to this. Lets say somebody goes off and does
something crazy like write a new provider in the next release. We can
now easily choose to backport that provider to Ubuntu 12.04 without
breaking all 12.04 deployments.

Anyway, don't let the multiple PPA's/series color your thinking too
much on this. These will be automatic daily build PPA's from said
series, so there will be very little maintenance involved. We're just
giving our early beta testers a chance to choose when they break their
deployments/clients/etc., and our developers a clear runway to land
big changes.

[1] https://lists.ubuntu.com/archives/juju/2012-March/001337.html