api/cli compatability between juju minor versions

Sun Jul 27 06:57:27 UTC 2014

My Juju Stable API Versioning
<https://docs.google.com/a/canonical.com/document/d/1fPOSUu7Dc_23pil1HGNTSpdFRhkMHGxe4o6jBghZZ1A/edit#>
discussion
was intended that we have to maintain an API compatible with 1.18 for at
least most of the lifetime of trusty (5 years).
That means supporting Version 0 (aka what was in 1.18) for that lifetime.
I think we still work ok with bootstrap, etc. 1.20+ clients should be able
to fall back to 1.18 mode, and 1.20+ servers should still serve the 1.18
API.
Now, whether everyone actually writing the code is actually ensuring that,
I can't actually guarantee, but we *do* have API versioning, and a way to
maintain compatibility with 1.18.

I'm guessing that unless we add CI tests that it works, we won't really
know that it works. :)
I do think 1.18 is our "must support" version in the 1.x series, since that
is what is in the Trusty archive. There has talk about once it is properly
vetted getting 1.20+ into backports/the main archive. And then using a
packaged named "juju2" if we need to break compatibility for some reason.

John
=:->

On Sat, Jul 26, 2014 at 12:49 AM, William Reade <william.reade at canonical.com
> wrote:

> On Sat, Jul 26, 2014 at 7:56 AM, Curtis Hovey-Canonical <
> curtis at canonical.com> wrote:
>
>> Ladies and Gentlemen.
>>
>> The Juju QA meet with Robie Basak to discuss backporting juju 1.20.x
>> to trusty. Robie was planning to supersede 1.18.1 with 1.20.2. I
>> suffered an anxiety attack.
>>
>> My current understanding is that we promise API/CLI compatibility
>> between one minor version and the next. Features are can be
>> deprecated, and they can be removed in the next minor release. Thus
>>   1.18.1 > 1.20.2 will work
>>   1.18.1 > 1.21.0 may not work
>>
>
> I'm rather bothered that this notion still has currency. We could get away
> with that in the past, but juju is in trusty, and we can't go breaking
> people now. Any significant changes to the CLI or API need to be saved up
> for a juju 2.0.
>
> It's fine to add new features, so long as they fail gracefully when
> attempted against older environments -- but if you're removing or changing
> an API, or removing or changing the meaning of a command line flag, you are
> Doing It Wrong. Developers, team leads, since there has apparently been
> some lack of clarity: be told, again, loudly:
>
> Thou Shalt Not Break Compatibility With 1.18. We Are Stuck With It.
>
> This scenario outline what can happen:
>>
>>     An enterprise machine uses trusty and juju 1.18.1 It manages several
>>     permanent 1.18.x environments [1]. The machine also has several juju
>>     scripts to create and destroy juju envs to do ephemeral work.
>>     The machine doesn't get package updates from 1 year.
>>
>>     Package updates are enabled; juju 1.25.0 is installed. The users of
>>     the machine didn't see the package was updated, they know nothing of
>>     the new features. Can they still manage there eternal 1.18.x envs? Do
>> the
>>     automated scripts continue to create and destroy ephemeral envs [2]
>>
>> As Ubuntu promises stability within a series, we cannot replace a well
>> understood juju with newer version of juju that redefines or removed
>> features.
>>
>> I know that the client is responsible for provisioning during
>> bootstrap and add-machine. Redefinitions of behaviours can happen. I
>> think they already have. For example, I see
>>     commit 5d0c7aeb7d3049672df587cb11f455465cce4a57
>>    [bug=1302005] cmd/juju: deprecate --series, added --upload-series
>> introduced in 1.19.2 as a planned change. 1.20.2 still supports
>> --series. I can see that 1.21-alpha1 still supports --series, but when
>> is --series obsoleted?
>>
>
> I don't think we can drop --series.
>
> I also don't think any juju code can ever be relied upon to provision any
> juju version different to itself, which may indicate a subtle bug around
> client add-machine for the manual provider... Andrew, do you think it could
> be reasonable to push that into the provisioner? We'd need to distribute
> the env public key to the machines being added, but that doesn't seem like
> the end of the world...
>
> If Juju is going to promise api/cli compatibility support for more
>> than 1 minor version, how long do we support? 2 years? Precise is more
>> than 2 years and we see the series is still popular.
>>
>
> LTS. 5 years. I tend to abbreviate this in casual conversation as
> "forever" because it seems to put people in the right mindset.
>
> Eventually, Juju will want to break compatibility, maybe it will need
>> to. Ubuntu will need to create co-installable packages. Users will
>> knowingly install newer version of juju to get new features. Old
>> versions will still be installed an usable. User can reinstall old
>> versions if they discover compatibility issues they cannot mitigate
>> quickly.
>>
>
> Those breaks should be saved up for major version upgrades.
>
> Cheers
> William
>
>
>>
>> [1] We know that trusty 1.18.1 client users are deploying and
>> upgrading envs to 1.18.4. We know these version are compatible
>>
>> [2] The new envs will be 1.24.x
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140727/c90c4732/attachment.html>