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
Rob Miller wrote:
thinking about it now, though, i'd say perhaps the zcml should support only
including a source version, with the setup tool persisting the id of each
upgrade step when it is run. then the UI would show an upgrade step as
needing to be run if a) the loaded profile version
Previously Maurits van Rees wrote:
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.
Previously Rob Miller wrote:
Maurits van Rees wrote:
Hi,
I wonder what the best way is of specifying the source number of a
GenericSetup upgrade step.
---SNIP a bunch of stuff about how using versions to mark GS upgrade steps
is
annoying---
yes, as you discovered, using source
Summary of messages to the cmf-tests list.
Period Thu Apr 16 12:00:00 2009 UTC to Fri Apr 17 12:00:00 2009 UTC.
There were 7 messages: 7 from CMF Tests.
Tests passed OK
---
Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.6 : Linux
From: CMF Tests
Date: Thu Apr 16 21:25:42 EDT 2009
URL:
yuppie, on 2009-04-17:
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
yuppie wrote:
Rob Miller wrote:
thinking about it now, though, i'd say perhaps the zcml should support only
including a source version, with the setup tool persisting the id of each
upgrade step when it is run. then the UI would show an upgrade step as
needing to be run if a) the loaded
