I would add to this, that there are equivalent changes in MAAS (maas-cli example), and its interaction.
With the changes, its also from a user perspective at least- that we maintain some level of documentation for installations, in which old docs that are our reference architectures, or install docs, become suddenly deprecated. At which point it becomes a "oh that changed". On the field, that's potentially detrimental in terms of "having to figure out the changes" on the fly at a customer site. I am willing to help with this, from a documentation perspective to test our deployments etc, and assist in any way I can. (I dont want to come across as just as a "complaint", without offering some level of assistance.) Regards, Akash On Mon, Apr 21, 2014 at 5:26 PM, Mark Canonical Ramm-Christensen < [email protected]> wrote: > Beyond all of the above, we should discuss the value of keeping around old > binaries and allowing future versions of the juju command line tool to > automatically fall back to an old binary when talking to an old version of > a juju state server. > > I think all of this should go into the "upgrades" discussion next week. > > --Mark Ramm > > > On Mon, Apr 21, 2014 at 3:45 PM, Kapil Thangavelu < > [email protected]> wrote: > >> >> >> >> On Mon, Apr 21, 2014 at 2:39 PM, Aaron Bentley < >> [email protected]> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 14-04-18 11:53 AM, Kapil Thangavelu wrote: >>> > 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. >>> > >>> > >>> >> And how does that work with multi-user environments? Divergence >>> >> is inevitable. >>> >>> >> For stable versions we should be compatible across micro releases >>> >> and testing the same, --version still seems good for users who >>> >> want exact behavior/reproduction. >>> >>> You make a good point, and we are going to look into testing across >>> micro-releases. >> >> >> Cool. >> >> >>> That said, I don't know whether we should expect a >>> lot of diversity or a little. People who upgrade frequently and >>> organizations that use Landscape to manage upgrades may not see much >>> diversity. >>> >>> >> I touched on this in the omitted parts of my previous reply. Landscape >> usage on clients is a small fractional portion of our intended user base >> (ie. a rounding error imo). Windows, OSX, users that stay on LTS are a much >> relevant portion our makeup, so pushing client versions to LTS and making >> windows and osx client updates available is important. Go happens to make >> most of that trivial (cross compile from linux for binaries on those >> platforms) such that its worth considering hosting static binary releases >> so users can get the latest and greatest regardless of their platform. >> >> -k >> >> >> >> >>> Aaron >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1 >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iQEcBAEBAgAGBQJTVYH3AAoJEK84cMOcf+9h2fIIALlfa2jL/aQtI9cCsLuQblwK >>> akzhaN+hlnaVfWNcvuVW6tB84CP23H9hNK259g+wJYgL+j0BAzisZMFrUvb4revg >>> QQpLhUHHCkGxBCGBir8mhDq+NPGPHdgR+S58CJDcKhF3w5hRBSrhSc+2gHighr1S >>> NaoqdO/KBo7nOqm1zjsOBXnoPdaEPPnXUbi7PC5sAGQB5hJY1JlyIG06x1JkahcU >>> Rhujug8Chvqd6BACvNsOm44l0xoAwD+wOh9HsemNjY/eMcn+RRxJTt91M6J08xvT >>> 8MBQP9x18cYyq+js/Re4DD5cUmdw5TaUjloiYczlI7b8hiSmMfO+xTwyXotu9mc= >>> =Qsul >>> -----END PGP SIGNATURE----- >>> >> >> >> -- >> 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 > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
