On Wed, Apr 29, 2015 at 10:10 AM, roger peppe <[email protected]> wrote:
> On 28 April 2015 at 19:32, Aaron Bentley <[email protected]> > wrote: > > On 2015-04-28 11:42 AM, roger peppe wrote: > >> The .jenv code was introduced prior to 1.16. How far back in time > >> do we need to preserve compatibility? (genuine question) > > > > We need to support every mode of operation that 1.18 supported. Juju > > has a special exemption that allows minor releases, rather than > > micro/bugfix releases, to added to Ubuntu. But in order to use that > > exemption, new versions of Juju are supposed to be equivalent to a > > micro/bugfix release in terms of their compatibility. > > So in general version 1.n will need to support every > mode of operation that version 1.n-1 supports? By induction > doesn't that mean we can never remove any features at > all ever from Juju, because every version will need > to support every mode of operation supported by > *all* previous versions? > All supported previous versions, yes. Otherwise we're not really supporting them. This is not a new requirement. I'd prefer to think that we can decide on a path forward, > create migration tools if necessary, and eliminate old, > confusing and velocity-impairing cruft from the code > when possible. But I freely admit that I'm code-biased > in this view :) > > > We had our own IS people upgrade to juju 1.20 from 1.18 and find that > > juju no longer worked. That's terrible. > > Would it have been so terrible if the release notes had said "to upgrade > to juju 1.20, run this tool to transition your existing local environment > store first"? > Yes, I think it would. It's not reasonable (or even possible, in the general case) to have every user of a given environment upgrade their client in lockstep with the environment; we'll *always* have to deal with old-client/new-server, *and* vice versa, across a bunch of releases. Compatibility code is frequently ugly, and heavy, but none of that makes it any less critically necessary. Cheers William > > cheers, > rog. > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
