New feature for charmers - min-juju-version

[David Ames]

On 03/21/2016 06:54 PM, Stuart Bishop wrote:
> On 22 March 2016 at 11:42, Rick Harding <rick.harding at canonical.com> wrote:
>> I believe that went out and is ok Stuart. The charmstore update is deployed
>> and when you upload a multi-series charm to the charmstore it creates
>> separate charms that work on older clients. If you hit issues with that
>> please let me know.
>
> Its only fixed for charms served from the charm store. CI systems and
> such test branches, for example ensuring tests pass before uploading a
> release to the charm store. I suspect this is exactly what Ryan needs
> to do and why I mentioned the open bug. Unless 1.25 is updated to
> handle the different data types, CI systems will need to work around
> the issue by either roundtripping through the charm store (in a
> personal namespace to avoid mid air collisions) or munging
> metadata.yaml.

This is correct. OpenStack charms will be affected. For much of our CI 
before publishing to the charm store we pull from branches both git and 
bzr. Using 1.25 we will either have to delay implementing series in the 
metadata.yaml or we will have to work around and alter metadata.yaml on 
disk.

Having a juju solution for Bug#1545686 would greatly help our testing.

--
David Ames

>>>> Rationale and use case:
>>>> A single Keystone charm supports deployment (thereby enabling continued
>>>> CI &
>>>> testing) of Precise, Trusty, Wily, Xenial and onward.  It is planned to
>>>> have
>>>> a min-juju-version value of 1.25.x.  That charm will support >= 1.25.x,
>>>> including 2.x, and is slated to release with 16.04.  This is
>>>> representative
>>>> of all of the OpenStack charms.
>>>
>>> Bug #1545686 will cause you issues too, unless you are always testing
>>> charms served from the store rather than local branches. 'series' is
>>> more involved than min-juju-version, as the data type change to the
>>> existing setting causes old versions to fail.
>
>
>