What happened to pinned bootstrap

[Akash Chandrashekar]

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 <
mark.ramm-christensen at canonical.com> 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 <
> kapil.thangavelu at canonical.com> wrote:
>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 2:39 PM, Aaron Bentley <
>> aaron.bentley at canonical.com> 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
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140421/1ac5616b/attachment-0001.html>