-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14-04-18 06:28 AM, William Reade wrote: > As for automatically upgrading: it's clearly apparent that there's > a compelling case for not *always* doing so. But the bulk of patch > releases *will* be server-side bug fixes, and it's not great if we > generally fail to deliver those to casual users.
I think that users should upgrade their clients in order to get bug fixes. I think that users who don't upgrade their client are expecting to get a lock-down experience, bugs and all. I don't think it's a good idea to default to deploying untested software combinations, especially when using a tested software combination will give a superior experience (i.e. client-side bug fixes). Even though you don't intend to introduce incompatibilities with old clients in patchlevel updates, we're human and mistakes happen. CI found lots of compatibility-breaking mistakes in the 1.17 series, and I'm sure there were many more that were caught by code review and juju-core's unit tests. The way to be certain we don't introduce such incompatibilities is testing with every patchlevel of the client, and that scales an already-big workload linearly with the number of patchlevels. There is value in using the latest patchlevel of the agent code. There is risk in using untested client/agent combinations. It is hard to weigh one against the other, and I say we don't have to-- we can get the value without introducing the risk by upgrading the client. > I'm inclined to go with (1) a --version flag for bootstrap, > accepting only major.minor >= client tools and (2) a --dry-run flag > for upgrade-juju (with the caveat that you'd need to pass its > result in as --version to the next command, because new tools > *could* be published in the gap between the dry-run and the, uh, > wet one). Aaron, even though this doesn't promote your use case to > the default, I think this'll address your issues; confirm? - --version would be an improvement, but we have a workaround, so it's not /that/ important. It's really the users I'm thinking of, the ones who care about reproducibility. I'd honestly rather have - --bootstrap-host, because the lack of it is making our testing of the manual provider a bit weird. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUUYPAAoJEK84cMOcf+9h1l8IAJTlK7+6bhoAGSmD0uVvFjmN XjqO26yQcQT+YNBLK5cNt2L6/nFmUUjLg9B1XA/y4rX6zTGUKKk9Ge1iyrfWRXf7 ZQwWHgsMIKxTmVak9x12ack/0PQQ4/D8qoXcM5mVRDCyXJx+zVDnGSw7Cfq+5Td7 cL79xrJb9Eakhw4AUzDnW7MGMIlQQIFbkMpRoO5YBhSLN+DCf8mpXRapCKGVwxf6 oLBarulsDGuolE8641wz39vraYbOpVWZG6NVtK7hYSVjyF689rt1uitJD79ebDGc zhoKNBdGQQbDceORfK9wxQcK5072XwzZpIQTaQAPioqJ7BJQ+SL7RWksZdraVTU= =Fb/3 -----END PGP SIGNATURE----- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
