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 

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



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Reply via email to