Bootstrap scheme for Go port
clint at ubuntu.com
Mon Apr 23 16:40:41 UTC 2012
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
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
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.
More information about the Juju