juju min version feature

[William Reade]

On Mon, Dec 15, 2014 at 5:51 PM, Nate Finch <nate.finch at canonical.com> wrote:
> OK, so, many people in juju-core have talked about this with Eco, and we
> came to the conclusion that per-feature flags would be way too confusing for
> the charm consumer.  When I want to deploy a charm, I don't wnat to have to
> figure out what version of juju supports leader election so I can know if
> the charm I want is supported by my version of juju.  I just want to see a
> min version and compare it to my version of juju.

The idea was that consumers should never be presented with this
choice: they care about *workloads*, not about feature flags *or*
minimum versions. They say "juju deploy postgres" and juju says "sir
yes sir"; and they get the most recent version of the postgres charm
that can run on the environment they're using. IIRC the charm store
API has included an []warnings in the info results, from pretty much
v1 onwards, so we even have a pre-existing path for notifying people
that there is a more recent version available that's not being used.

> This does put a little more burden on charm authors, to do that translation
> themselves, but they would need to be able to do that anyway to understand
> what versions of juju support their charm.  This way we at least take that
> burden off the person deploying the charm.

To reiterate: *any* approach that puts the burden on *users* is
unacceptable. From their perspective juju needs to Just Work.

> Also, we very specifically only support min version.  This just means we'll
> need to be backwards compatible. There won't be leader election 2.0 that
> makes 1.0 not work.

...which is, well, the problem. What's the benefit of hamstringing our
future selves in this way? If we pre-emptively declare Compatibility
Forever we make it impossible to close the feedback loops that would
otherwise allow us to improve everyone's experiences. WRT leader
election in particular: leader election is evidently applicable in a
wide variety of contexts, but I bet there are some we haven't thought
of yet. I'm reluctant to declare that the approach we've agreed upon
is the best of all *possible* approaches -- it's just the best of the
ones we have yet been able to imagine.

Cheers
William