UX to upgrade a charm

[Gary Poster]

On 01/18/2013 05:49 AM, Nick Boettcher wrote:
> Hey Gary.
>
> Thanks for the reminder. We've talked about this in the past but it's
> never made it into the wireframes other than deeply buried in an old old
> version of the notifications panel. I'll add a reference to it in the
> current set of wireframes so we can discuss this further in Austin

Cool, thank you.

> (if
> we make it... damn snow).

uh-oh...

> Is this something we need to have resolved for 13.04?

Good question.  Assuming you are in Austin, that's something we'll want 
to hash out there.  Development prioritization will be a big topic, I 
think, and if we can't get to it by 13.04, then you won't need to.

Gary

>
> Cheers,
> Nick.
>
>
>
> On 17/01/2013 18:59, Gary Poster wrote:
>> Hi Nick.  Something we don't have right now that we want is UX to
>> upgrade a charm.  I filed this as bug 1100904.  For convenience, and
>> possibly for discussion, here's what I wrote for that bug's description.
>>
>> """
>> If a charm is not local, we should give a control to upgrade it.
>>
>> We can find out from the charm store whether a charm has a newer
>> version available, and highlight the charm in the environment if we
>> want to. Kapil says that the charm store needs an api to get current
>> versions of a group of charms, as an optimization.
>>
>> IIUC from my conversation with Kapil, even if we don't see a newer
>> charm available, we should still allow a charm to be upgraded. This
>> can trigger a hook to do make arbitrary changes. For the GUI charm
>> itself, for instance, the charm might see if a newer release or newer
>> branch were available, even though the charm didn't change. This
>> understanding should be verified with Kapil.
>> """
>>
>> Thanks
>>
>> Gary
>