Bootstrap scheme for Go port

[roger peppe]

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."
"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."

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

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.

We can then use the normal semantic versioning rules for comparison
of versions. We can even push development versions into the normal
repository if we want (2.0.2-alpha.1), although that would require
a tweak to the comparison algorithm to prevent inadvertent use
of pre-release versions.

I don't believe this breaks semantic versioning, which doesn't say
anything about incompatible changes *between* pre-release
versions (what otherwise is the point of a pre-release version?)

Here's a possible replacement rule C:

C. on bootstrap find and use the largest toolset at $URL that has
toolset $MAJOR == client $MAJOR && toolset $ARCH == server $ARCH &&
toolset $MINOR >= client $MINOR, including pre-releases only
if additionally toolset $PATCH == client $PATCH

Here's an implementation of semantic versions that implements
the above rule for version compatibility and comparison checks:

http://gopkgdoc.appspot.com/pkg/launchpad.net/~rogpeppe/+junk/version