Hi Tres!

Tres Seaver wrote:
yuppie wrote:
Tres Seaver wrote:
yuppie wrote:
Tres Seaver wrote:

If we had the upgrade machinery in place, we could scrap non-purging
mode altogether -- its purpose is to allow for "controlled" application
of changes to existing configuration without full replacement.
Well. If we don't use the non-purging mode we can't write changes as profile snippets. Should upgrade steps always be implemented in pure Python without using any XML files?

I would say that the "execute-while-parse" model of our current profile
import driver is wrong for upgrades, but it would be possible.  The
upgrade step could do the checking that a given "upgrade-only" extension
should be imported, and then import it (perhaps passing 'no_purge' as a

Meanwhile, we would disable / remove any UI for setting that flag
outside an upgrade.

I removed the UI for setting that flag long ago. But extension profiles are always applied in non-purging mode, so the upgrade machinery doesn't help us to get rid of that mode.

I also would like to get rid of it, but that is only possible if we have a delta profile machinery that supersedes extension profiles.

The CMF 2.1 branch is not as stable as it should be. Adding the 'upgrade steps' feature might be low risk, but the other changes on the sprint branch look more risky to me. I'm a bit afraid merging them will destabilize the 2.1 branch further.

I don't think so.  The other changes split out the UI for setting the
baseline profile (ordinarily done only at site creation) and showing
available extensions.  I think the cleanup there is highly unlikely to
cause instability:  the only change is that we no longer require (or
even allow) people to set extension profiles as "faux" baselines in
order to import them.

If you say so, I withdraw my objections.



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

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to