Bootstrap scheme for Go port
kapil.thangavelu at canonical.com
Mon Apr 23 15:01:12 UTC 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
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
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.
More information about the Juju