juju min version feature

[Stuart Bishop]

On 16 December 2014 at 21:36, William Reade <william.reade at canonical.com> wrote:
> On Tue, Dec 16, 2014 at 6:36 AM, Stuart Bishop
> <stuart.bishop at canonical.com> wrote:
>> I think we need the required juju version even if we also allow people
>> to specify features. swift-storage could specify that it needs 'the
>> version of juju that configures lxc to allow loopback mounts', which
>> is a bug fix rather than a feature. Providing a feature flag for every
>> bug fix that a charm may depend on is impractical.
>
> 1) If you're developing for 1.20, then I think the compatible-1.20
> flag mentioned above should work as you desire, until juju changes to
> the point where some feature is actively incompatible. (As stated
> above, I'm expecting there will be some degree of tuning the charm
> environment to the declared flags regardless.)
>
> 2) Expand on the impracticality a bit please? I imagine that when
> we're talking about bugfixes of the sort you describe, the proportion
> of charms that care about a given one will be small; tracking them all
> may be somewhat *tedious* for the developers, but I don't see it being
> especially difficult or risky -- and AFAICS it need not impact any
> charm developers other than those who need that specific flag.
>
> ...not that I'm really keen to define a flag for every bugfix :-/. Do
> you have a rough idea of how often you've wanted min-version so far?

Practically, as a charm developer I'll be developing and testing using
juju-stable (1.20.14) and would tag my charms as minversion 1.20.14
(or tagged compatible-1.20 if you prefer). I will not give a moments
thought to old versions of juju unless I have a special need for back
porting my work.

For example, I've recently implemented rolling restarts in a charm
(and will push this to charmhelpers). For now, it uses the peer
relation to coordinate things. IIRC, in older versions of juju you
could not use the peer relationship unless there was at least one
other peer and the relationship had been joined. That has since been
fixed, and I can rely on using the peer relationship even if I only
have a single unit reducing my code paths. I'm relying on this
behaviour, yet have no idea if this changed in 1.16 or 1.18 or 1.20.
Most developers will never even know the behaviour was different in
the past, since they are developing in the present. Developers can't
track what they are not aware of.

-- 
Stuart Bishop <stuart.bishop at canonical.com>