Bootstrap scheme for Go port

roger peppe roger.peppe at
Mon Apr 23 11:46:46 UTC 2012

On 20 April 2012 19:14, Clint Byrum <clint at> wrote:
> Excerpts from roger peppe's message of Fri Apr 20 04:18:51 -0700 2012:
>> On 19 April 2012 12:54, Gustavo Niemeyer <gustavo.niemeyer at> wrote:
>> >>> > 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.
>> I'm uncomfortable with this. It seems to break the well-specified
>> semantic version, erm, semantics.
>> "Each element MUST increase numerically by increments of one."
> Every example above only increments by one. The dev releases are still
> "releases".

Stretching the term a bit, perhaps!

> I find these extra tags cumbersome in practice, requiring extra logic
> to compare them and such. One good that comes of them is that its
> very obvious to people not in the know about the odd/even bit that
> the version is not to be trusted.

They might be cumbersome, but they are part of the semantic version
spec, so why not use them? They seem to me to be a good fit
to our problem space.

Also, the logic to compare them is already implemented.

More information about the Juju mailing list