Bootstrap scheme for Go port

[Gustavo Niemeyer]

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

Indeed.

> Why don't we use the pre-release version for this?

The pre-release scheme is equally unsuited for that, for the same
reasons you bring up. We can use the build scheme with pluses, though.

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

In addition to the above point, we have to define properly how the
build releases look like for the project. E.g. we shouldn't have
different version style depending on who's built them (IOW, no "rog").

Perhaps something like this:

    $MAJOR.$MINOR.$PATCH+bzr$REVNO

The $REVNO there is just a hint and shouldn't be used in comparisons,
since we will always have multiple branches with matching revision
numbers.

> We can then use the normal semantic versioning rules for comparison
> of versions.

As I understand it, we'd be using it anyway with the original proposal.

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

That's a good idea. It should not update to pre-releases or to builds
without explicit allowance.

> 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

This doesn't seem much different. The fact someone is in a patch
version is not a flag to whether this person wants to upgrade to a
pre-release or to a build. An explicit allowance should be given for
upgrade-juju to pick non-stable releases.

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

Cheers, will look at the CL.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.