If the released Juju 2.0 uses v5 of the charmstore API (which it will soon hopefully anyway when my branch to support the new publishing model lands), then there's a straightforward solution here, I think: change v4 of the charmstore API to refuse to serve min-juju-version charm archives to clients. Since the only v4-using clients should be old juju versions, this could provide a reasonably cheap to implement and straightforward solution to the problem.
On 18 March 2016 at 09:49, Uros Jovanovic <[email protected]> wrote: > We’re looking in how we can identify 1.x Juju client/server in such a way > that at the same time we don’t block access to charms for other clients > using our HTTP API. > > > On Fri, Mar 18, 2016 at 9:34 AM, Mark Shuttleworth <[email protected]> wrote: >> >> On 17/03/16 22:34, Nate Finch wrote: >> > Yes, it'll be ignored, and the charm will be deployed normally. >> > >> > On Thu, Mar 17, 2016 at 3:29 PM Ryan Beisner >> > <[email protected]> >> > wrote: >> > >> >> This is awesome. What will happen if a charm possesses the flag in >> >> metadata.yaml and is deployed with 1.25.x? Will it gracefully ignore >> >> it? >> >> >> >> I wonder if there is a clean way for us to have Juju 1.x reject the >> charm very early in the process, giving an error that would essentially >> amount to the "not understood"? Or if we could have the charm store >> refuse to serve up the charm to a 1.x Juju client / server? >> >> Mark >> >> -- >> Juju mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju > > > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
