Bootstrap scheme for Go port

[Gustavo Niemeyer]

On Mon, Apr 23, 2012 at 10:02, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
>> Perhaps something like this:
>>
>>    $MAJOR.$MINOR.$PATCH+bzr$REVNO
>
> Actually, I take that back. People *will* look at the $REVNO if we do
> this, and there's a strong temptation to use that in comparisons,
> which is wrong.
>
> I instead suggest something as simple as this:
>
>     $MAJOR.$MINOR.$PATCH+dev

Roger pointed out that the above doesn't work because +whatever in
semantic versioning is actually applied in the *previous* version
rather than the candidate one, and thereafter we spent a while
debating about this, and I also kept thinking further over the
afternoon.

The basic concept we envisioned would look something like this:

    $MAJOR.$MINOR.$PATCH(-dev$MARK|-pre$N)?

There was quite some debate about what $MARK would mean. The
difficulty in defining it well is that there are a few requirements
that we were trying to cover:

V1. It should enable upgrading a development environment from branch A
to branch B and then back to branch A or on to branch C which may have
contents which diverge from A, as that commonly happens over the
course of development.

V2. It's tempting to tie in the revision information from bzr, but
that conflicts with the point above, and would create issues in terms
of management of changes in dependencies ("I changed gozk and want to
test it; how do I upgrade the environment to it?")

V3. Ideally it must define an ordering so that even with the above
requirements, it's still easy to make comparisons both in code and in
our heads.

V4. This will be part of the version string, which means it must be
embedded within the binaries so that "juju version" and so on works;
this means it must be known at build time.

V5. It's oriented for humans too, so short and simple is good; this
means avoiding things like 1.2.3-pre4+dev5)

V6. The Go side of the development team will certainly agree that "go
get" should work (note that this excludes any actions at build time!)

V7. Ideally it would help the use of versions in packages; 1.0.0-pre1
before 1.0.0 works, but the pre1 has to be detached onto the release
to enable the upgrade afterwards. It's doable, but not ideal.

V8. Ideally it'd also respect semver.org entirely

This is tough. I don't think there's a single solution that works for
them all. V6 wasn't part of the debate today, and since we're talking
about development versions, this is very desirable and removes several
possibilities; we're basically restricted to building the development
version string from content that was already on the tree.

So, with all of that considered, I suggest we go back to the original
proposal, and do:

VA. odd/even separation; an odd number in any of major, minor, or
patch version means it's unstable and prone to changes

VB. upgrade-juju will have a --dev flag to enable upgrading to
anything odd (quite appropriate pun)

VC. upgrade-juju --dev will also *force* the upgrade, in the sense
that it will replace the toolset pack in the storage provider
irrespective of version comparisons, and will ask all agents to
restart with it

That's the proposal. It addresses points V{1,2,4,5,6,7} , and leaves V{3,8} out.

I think most people were already happy with that before, and I hope
this is good background to extend the agreement so that we can move
forward.

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

-- I'm not absolutely sure of anything.