New feature for charmers - min-juju-version

[roger peppe]

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 <uros.jovanovic at canonical.com> 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 <mark at ubuntu.com> 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
>> > <ryan.beisner at canonical.com>
>> > 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
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>