This sounds like a good idea. The bug which I ran into (which I'm assuming is the source behind this query) would be very difficult to debug by users who didn't realize that there was a new juju release and they have not yet updated the client.
-Jeff Kapil Thangavelu wrote: > sounds like a great case being made for --upload-tools by default. > > > > On Sun, Mar 30, 2014 at 12:23 AM, John Meinel <[email protected] > <mailto:[email protected]>> wrote: > > I thought at one point we were explicitly requiring that we > bootstrap exact versions of tools (so juju CLI 1.17.2 would only > bootstrap a 1.17.2 set of tools). We at least did 1.17 will only > bootstrap 1.17, but looking at the code we still always deploy the > latest 1.17 (which broke all the 1.17 series of CLI because 1.17.7 > has an incompatible required flag). > > There is an argument that we can't get away with such a thing in a > stable series anyway, so it isn't going to be a problem. Mostly, > though, I had thought that we did exact matching, but I can see > from the code that is clearly not true. > > Would it be very hard to do so? I think William had a very > interesting idea that CLI bootstrap would always only bootstrap > the exact version of tools, but could set the AgentVersion to the > latest stable minor version, so it essentially bootstraps and then > immediately upgrades. (With the big benefit that the upgrade > process to migrate from old versions to new versions gets run.) > > This could be a distraction from the other stuff we're working on, > but it doesn't look that hard to implement, and would avoid some > of these semi-accidental breaking of old tools. > > John > =:-> > > -- > Juju-dev mailing list > [email protected] <mailto:[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
