[Product-Developers] Re: GS upgrade step docs and tests

Gilles Lenfant gilles.lenfant at ingeniweb.com
Tue Jul 1 09:37:03 UTC 2008

Le 30 juin 08 à 20:30, Rob Miller a écrit :

> Derek Richardson wrote:
>> Gilles Lenfant wrote:
>>> Le 26 juin 08 à 17:23, Derek Richardson a écrit :
>>>> My question. I have v1 of a product that contains GS for  
>>>> utilities A and B. In v2, I am adding a utility C. If someone  
>>>> upgrades, I want them to get C without re-installing A or B, to  
>>>> prevent data loss. However, if someone installs v2 fresh, I want  
>>>> them to get A, B, *and* C. Will registering an upgrade step for  
>>>> v1 to v2 that installs C accomplish this? I imagine it does, as  
>>>> the upgrade step would be of limited utility without this  
>>>> functionality, but haven't seen this explicitly stated anywhere.
>>> Yes it does. The handler of an upgrade step is just a function  
>>> that has the portal_setup object(*) as argument. This function  
>>> only needs to add C, either programmatically or by running a GS  
>>> import step like this :
>>> def myUpgradeHandler(setuptool):
>>>    """Add only C to existing config"""
>>>    setuptool.runAllImportStepsFromProfile('profile- 
>>> my.component:upgrade_v1_v2', ...)
>>> Of course you need to register with some ZCML that extension  
>>> profile (upgrade_v1_v2 for my.component) that only contains  
>>> features of C. when the defaut profile contains A, B and C.
>>> (*) I would have preferred a "context" as in usual setup handlers,  
>>> such functions from setup handlers could be used easily from  
>>> upgrade steps.
>> Aha! So, I need to add the registration of C to the default profile  
>> to get it installed when someone does a fresh install *and* add an  
>> upgrade step that installs it when someone does an upgrade? I was  
>> hoping that the upgrade step would be automatically run after the  
>> default profile import, so that I would only have to do it in one  
>> place. Oh well...
> for now, yes, unfortunately.  this should improve soon, though.   
> sometime in the coming weeks i plan on implementing a  
> <genericsetup:rerunImportStep> tag, which would be able to be used  
> in all the places that a <genericsetup:upgradeStep> tag is currently  
> supported.  the rerunImportStep tag will be short-hand for saying  
> "upgrading from version X to version Y requires import step Z to be  
> re-applied to the site".
> when this is working, the process will be to a) modify the profile  
> definition and b) add the <genericsetup:rerunUpgradeStep> tag to  
> specify that the right import step be applied during the upgrade  
> process.
> i think this is acceptable, and (more importantly, perhaps) i  
> _don't_ think we should try to reduce it any further than this.   
> this feels to me like the right balance btn minimizing developer  
> effort and maintaining explicitness w/ what happens for each upgrade.
> -r
> p.s.: while the example given above will work, and while Plone  
> itself uses them, i'm generally not in favor of defining specific  
> "upgrade" profiles as full-fledged extension profiles.  now that you  
> can use upgradeSteps, there's not really a need for separate upgrade  
> profiles.  if everyone started registering upgrade profiles for  
> every version bump for every product, the profile registry would  
> quickly become a major PITA to use.


This is just an example. Of course a full upgrade profile would be  
overkill to add only a couple of properties. The developer has just to  
use well balanced and suited resources to the stuffs added at upgrade.

Gilles Lenfant
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline
1 rue Royal
92210 Saint Cloud
web : www.ingeniweb.com - « les Services Web Ingénieux »

More information about the Product-Developers mailing list