Bootstrap scheme for Go port

[Gustavo Niemeyer]

> (I totally forget the details, but...) For example, there was some
> upstart stanza that I wanted to use in the stability work, but I
> couldn't because it's not available before the version shipped in
> Precise. Fine, for now; but next time someone's working on that code,
> once Oneiric is no longer supported by Juju, they're probably going to
> drop the workaround; at which point, bam, that version of Juju becomes
> undeployable on Oneiric.

It's fine for an unsupported release to not work. The problem being
addressed by the suggested procedure is to enable us to support things
we want to. We can't do that today.

> I doubt this will be the only such case we encounter; hence my
> suggestion that we flat-out disallow deployment to serieses without
> compatible released versions of Juju.

The version of juju in the released Ubuntu series is not important. If
we release juju 4.0, we'll want it working in all currently supported
versions of Ubuntu, and in the upcoming one.

> Alternatively, we demand that all
> versions of Juju work in all relevant serieses forever... but (1) this
> is quite a burden to bear and (2) it also obsoletes the use case we're
> discussing, because we may as well just release Juju on every supported
> series forever. Am I missing something?

Run this idea through the checklist. Does it cover all of the
possibilities we want to support?

> The semantic versioning spec makes a distinction between 0.x and 1.x, in

This distinction is a red-herring.

> that breaking changes in 0.x don't have to correspond to major version
> bumps. I agree that nobody using 1.0.0 (hmm, 2.0.0, based on the
> suggestion below?) will care while we're working on a dev version, but
> I'm still not sure how we handle a cycle in which we implement two
> distinct breaking changes that land at different times...

If they were *released* (e.g. made into a tarball and announced), they
are two different major versions. This can happen within a single
cycle for sure, even more if we have good mechanisms for upgrading
across major versions as suggested, which I really hope we get right
from the get go in the port. Of course, this isn't a free pass to do
major versions every day.. we need to plan breakages well ahead of
time, and attempt to group them in a single release when feasible.

>> > 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 guess I'm confused... it seems to me that you are solving the same
> problem (albeit in different contexts), and that the two contexts will
> overlap (however briefly) at the point we switch official
> implementations, and I'm finding the transition hard to think about.
> What am I missing?

Please go over the initial list of goals. They're technical issues
that affect the actual code we have to write, and that's what we must
focus on. We can ignore the transition entirely for the moment.

>> 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
>
> LGTM, modulo uncertainty above. Consider:
>
> 4.2.4 is out in the wild
> We start work on a breaking change and call it 5.0.0
> We do a bit more development and get it up to 5.3.2
> We've still got time before the next cycle, and want to make another
> breaking change, so we... er...
> * can't go to 5.4.0, because that breaks semantic versioning.
> * can't go to 6.0.0, because that's a release version.
> * have to go to 7.0.0

5.0.0 is a development version. We won't be bumping the version on
every commit. Yesterday's 5.0.0 isn't the same as today's 5.0.0. The
main reason we have 5.0.0 at all is because we want to be able to test
4.X.X => 6.0.0 upgrades without releasing 6.0.0, but there's no reason
to have people testing 5.0.0 => 7.0.0 upgrades. If we do a second
incompatible change on 5, we tell people to shut it down and restart
the environment. We can also send flowers to those that upgraded their
production deployments to it, though. :)

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

-- I'm not absolutely sure of anything.