Maurits van Rees wrote:
> yuppie, on 2009-04-16:
>> I added several tests and cleaned up the behavior on the trunk:
>> 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')
> >>> e.isProposed(tool, '1.1.2')
> >>> bool(_extractStepInfo(tool, 'ID', e, '1.1.2'))
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