Version numbering, the release, and backwards compatibility

[Mark Ramm]

(Sorry list address got dropped from my reply)

I think juju-core is fine.   We may someday have a separate binary for 
juju client or something like that, so core feels reasonable to me, and 
more reasonable than 2.0 which will eventually go out of date no matter 
what we do.

--Mark


On 04/11/2013 01:29 PM, Martin Packman wrote:
> On 11/04/2013, Mark Ramm <mark.ramm-christensen at canonical.com> wrote:
>> We also had agreement based on the current state that the new go based
>> juju core should become the default, both in Universe and in the ~juju
>> PPA.  The python version 0.7 should also be explicitly installable via
>> update alternatives, and that 0.7 will likely be the "end of life" for
>> pyjuju.
> This work is done and awaiting inclusion in raring. I have a pending
> release announcement for juju 0.7 which mentions its eol status.
>
>> While huge progress has been made over the last month, I don't believe
>> we have enough charm testing completed to be completely ready to go for
>> the 2.0 moniker in this first release.
> My initial plan was to have the go juju binary package as juju-2.0,
> this could instead be juju-1.10 without issue. If we plan on doing
> more version bumps without compatibility breakage, it might be more
> appropriate to stick with juju-core instead. I take it we don't
> anticipate users needing client tools for 1.10 and 1.12 installed at
> the same time?
>
> Martin