Rob Miller wrote:
- Why is it necessary to use version numbers from VERSION.txt? AFAICS
it does not make much sense to keep profile version numbers in sync
with product version numbers. New profiles should have an explicit
version in metadata.xml, old profiles can use '0' as version number. No?
i could go either way. i thought that some folks, with products that
had fast release cycle, might choose to use the product version as the
profile version, so the product version is used as a failover if a
profile version isn't present. i don't feel strongly, though, and would
be fine to remove this if others disagree.
Well. I'd prefer to have *one* obvious and explicit solution. The
failover adds extra code that needs to be maintained and makes it less
obvious where the version number comes from.
- Why uses ProfileMetadata the old ImportConfiguratorBase?
ImportConfiguratorBase is just not deprecated because GenericSetup
still uses it in some places. But the goal was to get rid of it, not
to add new files that depend on it.
since it wasn't deprecated, or even commented, i didn't know the goal
was to get rid of it. sorry.
I am sorry. Looks like you spent a lot of time on figuring out how it
works and writing documentation :(
I wrote that code long ago, replacing the old pattern still used in
DCWorkflow's WorkflowDefinitionConfigurator. Later I figured out that
this extra framework is less flexible and not much easier to use than
the generic DOM API. All new code is DOM based and a big part of the old
code is converted.
If you agree that this code can be removed in the long run, we should
figure out how to document this decision.
- Why is exporting metadata.xml not supported?
because metadata.xml is not actually site configuration. it's metadata
on the profile itself. there's not any way, nor should there be, IMO,
that the information provided in the metadata file can be changed on a
live site in such a way that it would be exported. perhaps it would be
better to change the metadata to an .ini file, or some other config
syntax, to distinguish it more clearly from the rest of the profile.
If it is pure registration information, why don't we extend the ZCML
directive? But AFAICS data like the version number belongs to the
profile itself and it might be useful to add timestamp based version
numbers to exported profiles.
- How are profile dependencies specified, where are they used?
dependencies are specified in metadata.xml; syntax can be found in
test_profile_metadata.py. unfortunately, they're not used yet... this
was a goal that we didn't actually get to. :-(.
'DEPENDENCY 1' and 'DEPENDENCY 2' don't really explain how to specify
dependencies: Would we use identifiers like
'Products.CMFCalendar:default'? Is it possible to use version numbers?
As long as these questions are not resolved I would disable the support
for dependencies completely.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests