On 16 December 2014 at 21:36, William Reade <[email protected]> wrote: > On Tue, Dec 16, 2014 at 6:36 AM, Stuart Bishop > <[email protected]> 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 <[email protected]> -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
