Bootstrap scheme for Go port

[Gustavo Niemeyer]

On Thu, Apr 19, 2012 at 08:10, William Reade
<william.reade at canonical.com> wrote:
> On Thu, 2012-04-19 at 06:54 -0300, Gustavo Niemeyer wrote:
>> On Thu, Apr 19, 2012 at 06:39, William Reade
>> <william.reade at canonical.com> wrote:
>> >> 4. deploy in releases of Ubuntu older than the local machine, and have
>> >> them running the newest client that is compatible with the local
>> >> client (possibly newer than the latest distributed in the respective
>> >> release)
>> >
>> > I think we may need to be a little stricter here: ie you *cannot* deploy
>> > to a series whose latest released juju version is incompatible with the
>> > client.
>>
>> The juju in the deployed series is irrelevant here. If you have
>> concerns I'm not understanding, please bring them up in the proposed
>> solution so we can see how to fix them.
>
> I think I misunderstood the "respective release": if you're talking
> about the local release it's fine,

You had it right before.

> but it's just not going to be
> possible to deploy juju 3.x.x code to a series whose latest version of
> juju is 2.x.x. Er, this is obvious, isn't it? Sorry ;).

Haven't I just described a way to do what's obviously not possible?

> All fine: I'm not saying we shouldn't do it, just being explicit about
> the tradeoffs we're choosing.

Understood, and sounds good.

> It all hinges on what we consider to be 1.0.0 (I think that was proposed
> to be the first go version in the other thread?).

I don't think this is important. The whole plan works regardless of
how soon or late we brand the port as 1.0.0. What will happen is that
the more users the code gets, the more we'll be encouraged to sustain
$MAJOR unchanged. No one will care if we bump $MAJOR while everybody
is using what's in 12.04.

> We've been talking
> about incompatible minor versions, with no dissenting voices, and
> there's some uncomfortable tension between "still being 0.x" and "not
> wanting to mess with users" in the context of these plans.

I'm not solving the problems Clint has to address today. Clint is not
solving the problems being addressed in this proposal. They are
related, but disconnected in time and scope.

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

This has two nice benefits:

- enables us to upgrade from any released version to a development
version using the same mechanisms we'll normally use

- enables us to easily spot if someone is using a development release
in the wild

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

-- I'm not absolutely sure of anything.