Let's get real about releases

[Robbie Williamson]

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
> 


-- 
Robbie Williamson <robbie.williamson at canonical.com>
Director of Engineering, Ubuntu Server
Canonical

"You can't be lucky all the time, but you can be smart everyday"
 -Mos Def