On Mon, Dec 15, 2014 at 8:16 PM, Nate Finch <[email protected]> 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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
