Bootstrap scheme for Go port

[Clint Byrum]

Excerpts from roger peppe's message of Fri Apr 20 04:18:51 -0700 2012:
> On 19 April 2012 12:54, Gustavo Niemeyer <gustavo.niemeyer at canonical.com> wrote:
> >>> > I think this is a good use case for dev-mode as well.
> >>>
> >>> Not sure about what you mean here.
> >>
> >> Just that we'll need to be able to migrate released versions to dev
> >> versions, before those dev versions become released versions, so we can
> >> verify we can actually do the upgrades. Not meaningful until we have a
> >> migration mechanism in place, ofc.
> >>
> >> Did that help?
> >
> > It did, and it's a good point. To solve it, I suggest we split the
> > version space in odd/even across all of the numbers.
> >
> > 2.0.1 is a development version, and will be released as 2.0.2
> > 2.1.0 is a development version, and will be released as 2.2.0
> > 3.0.0 is a development version, and will be released as 4.0.0
> >
> > The version is changed in the code as soon as a new release is made.
> 
> I'm uncomfortable with this. It seems to break the well-specified
> semantic version, erm, semantics.
> "Each element MUST increase numerically by increments of one."

Every example above only increments by one. The dev releases are still
"releases".

> "Major version X (X.y.z | X > 0) MUST be incremented if any backwards
> incompatible changes are introduced to the public API."
> "Once a versioned package has been released, the contents of that
> version MUST NOT be modified. Any modifications must be released as a
> new version."

I see what you're getting at there. Since there needs to be an
intermediary step between committing to trunk, and creating one of these,
I don't see a problem though. When those releases are cut, the version
should be bumped. If its a dev release, only minor or patch versions
should be bumped.

> 
> Development versions will make backwardly incompatible changes are made to the
> public API all the time with respect to each other.
> 

I'm willing to make a small stretch and say that dev releases are not
"public API's". We're specifically saying, this is a dev release, and
so, no API guarantees are made. The mere bumping of the major version
at first during the dev cycle is a clear enough signal that "here be
dragons". We never really care about the painful upgrade path between
two dev releases, so we're not going to bump it until the stable release.

> Why don't we use the pre-release version for this?
> 
> That is, when I'm starting work on the version that will become
> 2.0.2, I can use a pre-release verson, say 2.0.2-rog.0.
> 

I find these extra tags cumbersome in practice, requiring extra logic
to compare them and such. One good that comes of them is that its
very obvious to people not in the know about the odd/even bit that
the version is not to be trusted.