<div dir="ltr">My <a href="https://docs.google.com/a/canonical.com/document/d/1fPOSUu7Dc_23pil1HGNTSpdFRhkMHGxe4o6jBghZZ1A/edit#">Juju Stable API Versioning</a> 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).<div>
That means supporting Version 0 (aka what was in 1.18) for that lifetime.</div><div>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.</div>
<div>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.</div><div><br></div><div>I'm guessing that unless we add CI tests that it works, we won't really know that it works. :)</div>
<div>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.</div>
<div><br>John</div><div>=:-></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 26, 2014 at 12:49 AM, William Reade <span dir="ltr"><<a href="mailto:william.reade@canonical.com" target="_blank">william.reade@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Sat, Jul 26, 2014 at 7:56 AM, Curtis Hovey-Canonical <span dir="ltr"><<a href="mailto:curtis@canonical.com" target="_blank">curtis@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Ladies and Gentlemen.<br>
<br>
The Juju QA meet with Robie Basak to discuss backporting juju 1.20.x<br>
to trusty. Robie was planning to supersede 1.18.1 with 1.20.2. I<br>
suffered an anxiety attack.<br>
<br>
My current understanding is that we promise API/CLI compatibility<br>
between one minor version and the next. Features are can be<br>
deprecated, and they can be removed in the next minor release. Thus<br>
1.18.1 > 1.20.2 will work<br>
1.18.1 > 1.21.0 may not work<br></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>Thou Shalt Not Break Compatibility With 1.18. We Are Stuck With It.</div><div class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
This scenario outline what can happen:<br>
<br>
An enterprise machine uses trusty and juju 1.18.1 It manages several<br>
permanent 1.18.x environments [1]. The machine also has several juju<br>
scripts to create and destroy juju envs to do ephemeral work.<br>
The machine doesn't get package updates from 1 year.<br>
<br>
Package updates are enabled; juju 1.25.0 is installed. The users of<br>
the machine didn't see the package was updated, they know nothing of<br>
the new features. Can they still manage there eternal 1.18.x envs? Do the<br>
automated scripts continue to create and destroy ephemeral envs [2]<br>
<br>
As Ubuntu promises stability within a series, we cannot replace a well<br>
understood juju with newer version of juju that redefines or removed<br>
features.<br>
<br>
I know that the client is responsible for provisioning during<br>
bootstrap and add-machine. Redefinitions of behaviours can happen. I<br>
think they already have. For example, I see<br>
commit 5d0c7aeb7d3049672df587cb11f455465cce4a57<br>
[bug=1302005] cmd/juju: deprecate --series, added --upload-series<br>
introduced in 1.19.2 as a planned change. 1.20.2 still supports<br>
--series. I can see that 1.21-alpha1 still supports --series, but when<br>
is --series obsoleted?<br></blockquote><div><br></div></div><div>I don't think we can drop --series.</div><div><br></div><div>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...</div>
<div class="">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If Juju is going to promise api/cli compatibility support for more<br>
than 1 minor version, how long do we support? 2 years? Precise is more<br>
than 2 years and we see the series is still popular.<br></blockquote><div><br></div></div><div>LTS. 5 years. I tend to abbreviate this in casual conversation as "forever" because it seems to put people in the right mindset.</div>
<div class="">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Eventually, Juju will want to break compatibility, maybe it will need<br>
to. Ubuntu will need to create co-installable packages. Users will<br>
knowingly install newer version of juju to get new features. Old<br>
versions will still be installed an usable. User can reinstall old<br>
versions if they discover compatibility issues they cannot mitigate<br>
quickly.<br></blockquote><div><br></div></div><div>Those breaks should be saved up for major version upgrades.</div><div><br></div><div>Cheers</div><span class="HOEnZb"><font color="#888888"><div>William</div></font></span><div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
[1] We know that trusty 1.18.1 client users are deploying and<br>
upgrading envs to 1.18.4. We know these version are compatible<br>
<br>
[2] The new envs will be 1.24.x<br>
<span><font color="#888888"><br>
--<br>
Curtis Hovey<br>
Canonical Cloud Development and Operations<br>
<a href="http://launchpad.net/~sinzui" target="_blank">http://launchpad.net/~sinzui</a><br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</font></span></blockquote></div></div><br></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>