api/cli compatability between juju minor versions

[William Reade]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140726/45c8ec62/attachment-0001.html>