Let's get real about releases

[William Reade]

On Tue, 2012-04-17 at 19:29 +1200, Robert Collins wrote:
> On Tue, Apr 17, 2012 at 5:50 PM, Clint Byrum <clint at ubuntu.com> wrote:
> > 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.
> 
> Juju is aim at cloud deployments, and the cloud APIs we work with
> don't have a release schedule (instead they are -very- careful about
> backwards compatibility).

They may not have schedules, but they do have releases; I count 21 EC2
API versions since May 2008, and I'm pretty sure that those aren't just
a series of automated trunk snapshots.

> Perhaps instead of aiming at a slow cadence, we could ratchet it up a
> knotch: make trunk always release quality, and put some effort into
> backwards compat.

This has always been the ideal; in practice, despite our noble
intentions and honest efforts, we fall short. There's certainly scope
for disagreement about the length of the cycles, and I imagine the
details will evolve.

However, we are demonstrably not capable of maintaining trunk in such a
way as to make it infallibly backward-compatible with every previous
version of trunk; to change the process to allow for *that* would be to
demand an exponentially-increasing QA effort for every commit, on top of
our already stringent and costly review process.

It's already *hard* landing a feature in Juju, and the review and
maintenance of long-term parallel branches take up a significant
proportion of our resources; IMO, to "ratchet it up a notch" is to run
the risk of stalling development entirely.

Cheers
William