Bootstrap scheme for Go port

[Clint Byrum]

Excerpts from Kapil Thangavelu's message of Mon Apr 23 08:01:12 -0700 2012:
> Excerpts from Gustavo Niemeyer's message of 2012-04-23 05:51:32 -0700:
> > On Mon, Apr 23, 2012 at 03:53, Kapil Thangavelu
> > <kapil.thangavelu at canonical.com> wrote:
> > > Looks great, we need this. Two comments though, since the version is
> > > effectively the same through the cluster (minus errors) what do we gain by not
> > > just using a single integer ala charms, ie. even minor version code drift is
> > > potentially problematic.
> > 
> > Please run through the list of goals and the implementation proposal
> > and try to apply the same logic with a single integer. You'll probably
> > figure why it won't cut. If not, please drop a mail again and we can
> > run through it.
> 
> please don't do that its patronizing and non responsive. 
> 
> sem-versioning here requires human interpretation and is error prone for 
> compatibility evaluation.
> 

s/requires/requires and enables/

Its a feature, not a bug. :) Rather than expecting we can get 100%
test coverage for this, we should make a best effort, but then enable
a release manager to step in and make things right.

> We already have a few examples from the last cycle of either backwards 
> compatible state changes accompanied by incompatible code changes or 
> incompatible state changes, in both cases the developers thought they where 
> compatible.

And as juju now moves from "rapid early evolution" to "widespread use"
those changes would be *reverted* in a stable release.

> 
> i'm suggesting rather than work via a 4 part version string and possibly a 
> testing infrastructure to validate the correctness, we just utilize a monotonic 
> increasing int. I'm also assuming the implementation of schema upgrades though 
> as part of this feature, such that the distinction between revs is varied based 
> only on the presence of an associated migration to the revision. 
> 

This would chase away any actual users pretty quickly. Users expect that
software will break every once in a while in a way the authors never
dreamed of. As a user of software though, I expect that these reports
will be responded to quickly, and fixes will be considered.

If we go with monotonically increasing numbers, we have no way to keep
moving forward *and* respond in a clear manner:

 * 2.2.0 releases with new features over 2.0.0
 * 2.3.0 opens, massive new feature lands with huge refactoring in code
 * security problem, 2.0.2 and 2.2.2 released with patch.
 * 2 weeks pass, users download 1.2.0 and install it for testing, 
   critical backward incompatible break is found.
 * 2.2.4 released with backward incompatible break fixed
 * 2.3.0 branch already has backward incompatible behavior as author 
   intended, now adds documentation of the difference + migration
   code and/or advice.
 * 2.3.0 becomes 3.0.0 because of backward incompatible break.
 
With monotonically incrementing integers...

 * 6 "releases" with new features
 * 7 introduce massive new features/refactoring
 * security problem, 5.1, 6.1 released with patches
 * 2 weeks pass, users download 6 or 6.1, testing, critical, etc.
 * release 6.2 with backward incompatible break fixed.
 * ... much the same, ending with a '7' releasing w/ the features and
   backward incompatibility.

Now, as a user, how do I know that 6 wasn't supposed to introduce
backward incompatible changes with 5 and that it is safe to upgrade to
it to take advantage of the new features? How do I know that I need to
run migrations from 6 -> 7? How do I automate security updates?

The scheme set down with all 3 parts is able to satisfy all of those
needs pretty easily I think.