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. So I agree that kill-controller should always work. We should only need provider configuration if it's not possible to destroy the provider via the API; and provider configuration compatibility should not be an issue if we're destroying via the API. Cheers, Andrew
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
