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) th
Wichert Akkerman, on 2009-04-17:
> 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
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
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 discove
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
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 ver
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
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
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 and destination versions to mark w
Hi Maurits!
Maurits van Rees wrote:
[...]
> Probably not relevant here, but for completeness sake:
>
> - Poi branch 1.1 has 1.1.x in its version.txt and does not have a
> metadata.xml.
>
> - Poi trunk has 1.2.x in both its version.txt and metadata.xml.
>
> I know that it is best to use both
Hi,
I wonder what the best way is of specifying the source number of a
GenericSetup upgrade step.
Use case
Case in point: Products.Poi, an issue tracker for CMFPlone. Between
version 1.1 and 1.2 there were changes that needed an upgrade step,
which I registered like this:
Works fi
11 matches
Mail list logo
