Bootstrap scheme for Go port

[William Reade]

On Thu, 2012-04-19 at 08:54 -0300, Gustavo Niemeyer wrote:
> On Thu, Apr 19, 2012 at 08:10, William Reade
> <william.reade at canonical.com> wrote:
> > 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?

Well, we can deploy it, but we can't have any guarantees it'll work,
will we?

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

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

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

The semantic versioning spec makes a distinction between 0.x and 1.x, in
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...

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

> 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
...and that feels weird to me, because users will then see a bump from
4.2.4 to 8.0.0 when we finally release (and means we need to make sure
there's a direct 4->8 migration available).

To be fair, that's not such a terrible thing -- weird isn't a
dealbreaker -- but I want to be sure I understand the proposal.

Cheers
William