Let's get real about releases

[Clint Byrum]

Great idea!

https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-juju-release-process

Excerpts from Robbie Williamson's message of Tue Apr 17 09:25:03 -0700 2012:
> Okay, I "get it" now.  BTW, this sounds like a **great** idea for a
> blueprint...eh hem ;)
> 
> On 04/17/2012 11:12 AM, Clint Byrum wrote:
> 
> > 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
> > 
>