juju min version feature

[William Reade]

On Mon, Dec 15, 2014 at 8:16 PM, Nate Finch <nate.finch at canonical.com> wrote:
> There was a big discussion about this in Brussels, and the conclusion was
> that we should not do per-feature flags in the metadata, because the list of
> all flags becomes too large too fast, and too hard to understand for people
> using charms.

There's nothing stopping us from defining meta-flags -- eg
"compatible-1.22" implies precisely the set of flags supported in
1.22, and will continue to work until there's a version of juju that
drops one of them.

> That is not to say that we can't have a list of features and the version at
> which they're available to help charm authors figure out the right min
> version to set.  Your idea of having juju talk to the charm store to get
> that info sounds great.

The charm store has to know about this regardless, so it knows what
charms to advertise to particular versions of juju.

> It's an interesting idea to get jujud to enable/disable features to simulate
> older versions of Juju so you don't accidentally use features that exist in
> newer versions of Juju than your charm specifies.... but that sort of seems
> like something that's beyond the scope of this project.

I think it's inevitable. Features will interact in surprising ways:
for example, consider default-hook and leader-deposed. Leader-deposed
runs in a weird and special hook context; a standard implementation of
default-hook will almost certainly fail messily if it runs
leader-deposed without knowing it's a possibility. (As it happens,
leader-deposed will ignore errors, so this wouldn't be *fatal* -- but
it'd still be unnecessarily messy. Error spam in the logs makes nobody
happy -- and I don't think we're in a position to assume that all
future surprise interactions will be so forgiving.)

Cheers
William