quickly-talk team mailing list archive

[Didier Roche <didrocks@xxxxxxxxxx>]

Le mercredi 16 février 2011 à 01:11 +0000, tony byrne a écrit :
> I think "upgrading" the user's code is fraught with risk. Most users
> would not be contributors but could easily bug-fix some of the quickly
> supplied code in their project. If an upgrade is automatic it would
> need to compare the user's code with the maverick supplied code, or
> perhaps even the lucid codebase, before overwriting. Perhaps the
> upgrade could be a user controlled process similar to upgrade-manager,
> listing the changes and allowing partial upgrades.
> 
>  Do you intend to upgrade projects or the templates in
> ~/quickly-templates or both ? What about chains of templates or
> projects derived from ~/quickly-templates/my_template ?
> 
> Assuming that the user's edits to their code "breaks" quickly supplied
> code seems like Cathedral thinking. It seems to me best to offer the
> best template/source tree to the user that we can then leave them to
> it. Poking changes into it ever 6 months seems wrong.

We have already done that in the past without major breakage. But at
this epoch, Quickly was more at a early stage and adding support like
launchpad integration and such was rather a nice surprise to the user
than anything else :)

In any case, all upgrades are transactions and can be easy reverted
(contrary to a package management). So, this is simply done by
committing the project before the upgrade if not done already, and then,
committing after it. So, revert is easy (and we won't try to upgrade it
again). I think that we can bzr revert also if some other part of the
upgrade went wrong quite easily. This hasn't be done so, but it's just 2
lines away.

Anyway, as already discussed with Michael, I fully agree with the
initial post of what we should do vs upgrade and refactoring :)

Cheers,
Didier