quickly-talk team mailing list archive

[Didier Roche <didrocks@xxxxxxxxxx>]

Hey everyone and happy new year!

Le lundi 20 décembre 2010 à 10:33 -0500, Michael Terry a écrit :

> My proposal for promises from the Quickly project:
> 
>  * Project-level features (like /opt and appindicators) will be added by
> upgrades.
>  * Refactoring will not be guaranteed to be upgradeable.
>  * Severe bugs will be fixed by upgrades.
> So #1 will be upgraded, #2 wouldn't, #3a would, #3b wouldn't, #3c would.
> 

It's more or less what we already provide from Quickly's start. So I +1
on that, explicit is better than implicit.

> * Upgrades are only guaranteed to work from adjacent stable releases
> (i.e. from 10.09 to 11.04, but not directly from 10.09 to 11.10).

[…]

> It's an open question in my mind whether we should also follow the LTS
> schedule of Ubuntu and promise working upgrades from Ubuntu LTS to LTS.
> This would tie the project closer to the Ubuntu project and may not suit
> the needs of, say, the Fedora project when and if we get templates for
> them.  But it would be useful for Ubuntu users.

Not really, it's slightely more complicated than that. We have two kind
of upgrades :
- global upgrade
- template upgrade

* I think Michael is referring here to template upgrade (upgrade.py in
ubuntu-application directory). This one can be handled by the policy we
want : LTS to LTS is a must IMHO. In addition to this, as we handle the
check by increasing level like:

if version < 0.1:
   […]

if version < 0.2:
   […]

if version < 0.3:
   […]

Let's say we were at 0.1, we will then upgrade to 0.2 and then to 0.3 in
a row, so it's not an issue there.

Those upgrade are done before the first command of the current template
is executed. The upgrade is also handling the case of quickly -t
other_template foo if other_template should be upgraded in the current
project.

So we can easily handling template upgrade like that. All is done
automagically so that the user don't have to bother with it (and the
counterpart is that the user has to upgrade, so we have to ensure, as we
do today, that the upgrade is bulletproof and optional is the original
code isn't there).

What we can do is to trash old upgrade before previous LTS release,
agreed.

* There is another kind of upgrade. This one is executed before any
quickly execution and corresponds to global upgrade. We only made that
once and should avoid to make them as it's slowing down the core. Global
upgrades are made before any quickly code introspection is done. That
means even when shell completion is executed (at first [Tab], the need
for a global upgrade is checked). We used that once for renaming the
template from ubuntu-project to ubuntu-application so that the user can
in its project: quickly [Tab] [Tab] and still see the commands from the
current (renamed) template without noticing that anything has changed!

I think that the policy for this global upgrade and their lifetime
should be done just wisely: obviously, this global upgrade is related to
ubuntu, and we can remove it right now as it was a transition before our
previous LTS, 10.04.

Didier