Hi Martin,
The GS BBQ sprint branch looks promising. So we can probably drop
this idea. But some (closing?) remarks are in order.
Martin Aspeli, on 2007-05-12:
> Maurits van Rees wrote:
>> As an example, when seen in the context of Plone, the upgrade from
>> beta 2 to beta 3 might mean going from generation 42 to 47.
>
> That's what I'd like to avoid. A "generation" as an abstract number is
> likely to be hard to manage, and a "this number must be the same as the
> name of an extension profile" may be awkard and typo-prone.
I changed things a bit and I can now imagine more general version
oriented strings in the name tag of a gs profile instead of only
integers. As long as it is sortable it should not make the code much
harder and it buys us flexibility. So v11_12 as a generation name
would be fine with me now.
And just registering a profile is enough now in my vision. A
SchemaManager or some other registering of an upgrade step is not
necessary anymore. You can add all needed info in the profile
registration itself:
<genericsetup:registerProfile
name="v1.1_1.5"
title="Migration profile to migrate eXtremeManagement version 1.1 to 1.5."
description="This profile contains configuration changes that are applied
during the migration from eXtremeManagement version 1.1 to 1.5."
directory="migrations/v1.5"
for="Products.eXtremeManagement"
provides="collective.generations.MIGRATION"
/>
>> I think this can be handled by simply registering a GS profile with
>> 'to_version' as the name..
>
> Not if version == the real release version. You don't want to build an
> algorithm that works out whether 2.0b1 is before 2.1rc3. :)
I am sure that there is some python code for this already. But I have
not looked.
Hm, but I see a Plone site that has 2.5.3-rc1 as the instance version
and the 2.5.3-devel as the next target version. So alphabetic sorting
may be too simple.
BTW, the BBQ branch explicitly lets you specify a sortkey (like 1, 2)
to keep a record of which profile comes first. But that is exactly
where the tests fail:
File "/home/maurits/instances/30/Products/GenericSetup/tests/test_zcml.py",
line 197, in Products.GenericSetup.tests.test_zcml.test_registerUpgradeSteps
Failed example:
step1.title
Expected:
u'Bar Upgrade Step 1'
Got:
u'Foo Upgrade Step 1'
That is on Zope 2.10.3 in an instance with the Plone 3 bundle, but
with GS switched to that branch.
> Again, I don't like the implictness of this, though. :)
And I do like it. :)
>> I propose supporting only GS steps. Do you think that is too strict?
>
> If doing an upgrade step just means to call the step, and the
> default/basic step implementation's __call__() calls a GS profile, then
> that's no more work, but leaves you with a lot more flexibility should
> you need it (or, should you just *not* need GS... sometimes, it may be
> overkill or too cumbersome to register a new profile).
The bbq code of course only handles GS profiles by default. So maybe
there is hope for a small upgrade utility in Plone after all. ;-)
>> My proposal does not need this explicit registering. Registering
>> profile-Products.Poi:1 implicitly registers a migration step from
>> generation 0 to 1.
>
> That's what I don't like about it. :) Trust me, when it comes to
> migrations, having explicit control will help you hugely. There mere
> availability of a GS profile shouldn't be enough to tell you that
> there's an upgrade step to be run.
So we register the profile with this option:
provides="collective.generations.MIGRATION"
I think that signals nicely that this is a migration/upgrade step.
(well, if this information is shown to the user anyway). Otherwise a
name 'v2.5_3.0' and a proper title would signal this too.
> Like I said, we can infer the profile name as a default from product
> name + migration step to-version, but I'd still leave the door open for
> an override (and for non-GS steps).
Okay, an override possibility can be useful.
> that's not the way people normally name utilities. The purpose of the
> utility is described by the interface.:
>
> getUtility(IVersionManager, name="Products.Poi")
>
> ... I want the version manager for Products.Poi. That's clear. :)
Agreed.
>> In my proposal we could probably do away with the minimum_generation
>> as required by the base zope 3 generations and only state the number
>> of the last generation.
>
> Sure. You need that if you're implicitly looking for and running
> generations. If you're stating a list of migration step versions, you
> don't need this - the latest one is always the last one in the list.
And in my current code there is no SchemaManager anymore. :)
>> That is my idea of Plone migration at least: migrating from the latest
>> stable version of 2.5 to the subversion branch of 2.5 is a bit iffy.
>
> I do it all the time. Running an svn version is what's iffy. :p
Okay. I was mostly thinking about the message you get that Plone
could not be migratated to the latest version, as there is not always
a migration step to e.g. "2.5.3 svn".
> Anyway... read Hanno's post, much of this may just be hot air right now,
> if Tres and Rob have solved it all already. :)
:)
--
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
"Do not worry about your difficulties in computers,
I can assure you mine are still greater."
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
