On 05/04/16 11:12, Andrew Wilkins wrote: > On Mon, Apr 4, 2016 at 8:32 PM Rick Harding <rick.hard...@canonical.com> > wrote: > >> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins < >> andrew.wilk...@canonical.com> wrote: >> >>> In a non-beta release we would make sure that the config changes aren't >>> backwards incompatible. >>> >> >> I think this is the key thing. I think that kill-controller is an >> exception to this rule. I think we should always at least give the user the >> ability to remove their stuff and start over with the new alpha/beta/rc >> release. I'd like to ask us to explore making kill-controller an exception >> to this policy and that if tests prove we can't bootstrap on one beta and >> kill with trunk that it's a blocking bug for us. >> > > Generally agreed, but in this case I made the choice of improving the > quality of the code base overall at the cost of breaking kill-controller in > between betas. I think it's fair to have a temporary annoyance for > developers and early adopters (of a beta only!) to improve the quality in > the long term. Major, breaking versions don't come around very often, so > we're trying to wipe the slate as clean as possible. The alternative is we > continue building up cruft forever so we could support that one edge case > that existed for 5 minutes. >
To backup what Andrew said, we had the choice of an annoyance between betas for early adopters/testers, vs a much larger effort and cost to develop extra code and tests to support a very temporary edge case. We'd rather put our at capacity development effort to finishing features for the release. Having said that, we should have included in the releases notes an item to inform people that any beta2 environments could only be killed with beta2 clients. We'll do better communicating those beta limitations next time. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
