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

[yuppie]

Hi Maurits!


Maurits van Rees wrote:
> yuppie, on 2009-04-16:
>> 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

If you add that test to the trunk this behavior will become officially 
supported...

> 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.

Well. I was focused on 'isProposed'. This is the definition:

         """Check if a step can be applied.

         False means already applied or does not apply.
         True means can be applied.
         """

Your result is False for a step that should be applied.

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

*All* unchecked steps are "not recommended, run on your own risk". The 
checker is just a restriction like versionMatch. In same cases it might 
still make sense to (re-)run these steps.

But I'm sure the UI can be improved. Please note that hiding these steps 
  better will also hide your unchecked step.


Cheers,

	Yuppie