[Zope-CMF] Best use of source numbers in GS upgrade steps?

[Maurits van Rees]

Hello yuppie!

yuppie, on 2009-04-16:
> Maurits van Rees wrote:
>> So my question is: is this a sane way of doing this?  Is it alright to
>> specify a version (or really a profile revision) as source when that
>> version does not yet exist?  It works fine as far as I can tell.
>
> AFAICS this will not work with GenericSetup trunk. Maybe you want to 
> show the upgrade step for *all* versions before 1.2? In that case you 
> don't specify any source version.

Yes, that is what I want.  Looking at the trunk code, setting '*' as
source should have the exact behaviour that I want.  Sweet!

> BTW: The relevant behavior is quite inconsistent in GenericSetup
> 1.4.

Right, in the 1.4 code I see for example that the destination number
is never actually used, apart from showing it on the upgrades tab.

> I added several tests and cleaned up the behavior on the trunk:
> http://svn.zope.org/*checkout*/Products.GenericSetup/trunk/Products/GenericSetup/tests/upgrade.txt
> Please let me know if I did break useful behavior.

Ah, that looks much saner, thanks!  Nothing breaks here AFAICT.

And this tells me that my way of specifying source=1.1.9 and dest=2.0
should still work.  A snippet of those tests adapted to my numbers
gives this result:

  1.1.9 (source) > 1.1.2 (current) < 1.2 (dest)

      >>> e.versionMatch('1.1.2')
      False
      >>> e.isProposed(tool, '1.1.2')
      False
      >>> bool(_extractStepInfo(tool, 'ID', e, '1.1.2'))
      True

So the version does not match and the step is not proposed, but the
step info is extracted anyway, and as far as I can see this is what
matters in the end, as this is called in listUpgradeSteps.

BTW, do I understand correctly that when in this example we add a
checker that returns False the step will still be shown?

Specifying '*' instead of '1.1.9' as source is conceptually better and
works just as well on trunk.  But on GS 1.4 this has the effect of
always listing that upgrade step, as the current version is never
compared to the destination.

To get the exact same behaviour on 1.4 as on trunk I guess I could
copy the versionMatch code from trunk and add that as a checker to my
upgrade step...  Seems silly though. :-)


Okay, my conclusion: I will stick to specifying 1.1.9 as source in
this case.  Alternatively I will use '*' as source and make very sure
that running those upgrade steps a second time has no adverse effects
and is fast.  And for an upgrade step in a package that is meant for
GenericSetup/Plone trunk I will use source="*".


Since I made some notes while investigating, I might as well share
them.  So here are some random observations for reference, with some
CMFPlone versions thrown in for good measure.

- GS 1.3.3 is used in Plone 3.0.6.

- GS 1.4.1 is used in Plone 3.1.7.

- GS 1.4.2.2 is used in Plone 3.2.2.

- GS 1.4.2.2 is used in Plone 3.3rc1.

- GS trunk (1.5) is used in Plone trunk (4.0).

- The upgrade.py file is exactly the same in GS 1.3.x and 1.4.x, so
  upgrade step behaviour should be the same in Plone 3.0-3.3.

- Checkers:

  - GS 1.3/1.4: if a step has a checker, then the source and
    destination do not matter anymore: only the return value of the
    checker matters.

  - GS trunk (1.5): if a step has a checker, then its return value is
    used together with checks on the source and destination numbers.

- Destination:

  - GS 1.3/1.4: the version destination does not matter at all (!) as
    it is not used anywhere apart from being shown in the UI...

  - GS trunk (1.5): the destination matters, as it is compared to the
    currently applied profile revision.


-- 
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]