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