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
flag).
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.
Cheers,
Yuppie
_______________________________________________
Zope-CMF maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
