quickly-talk team mailing list archive

[Michael Terry <michael.terry@xxxxxxxxxxxxx>]

On Wed, 2011-02-16 at 01:11 +0000, tony byrne wrote:
> 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 ?

I think I wasn't clear.  When I say 'upgrade' I mean only upgrades of
project_root code in the user's project when that user runs 'quickly
upgrade'.  So it's a manually triggered process and doesn't touch
templates.

It's not that I think user modifications of the project_root code have
broken anything, but that user modifications of the project_root code
make it difficult to successfully upgrade code.  That's why I want to
separate them a bit.

But your feeling that we can just give them code and they'll deal with
it is good.  That's by and large what we do, but I'd like the capability
of upgrading if needed (i.e. some bug that we fix that not everyone may
have fixed).  Usually though, we do it to add new features (like
indicator support or whatever) and the new layout would make that much
easier.

Since you seem unconcerned about upgrading, I'm assuming your answer to
the question of whether it is OK to refactor like this without allowing
upgrading into it to be that it is OK.

-- 
mterry