Hi,
I think it is impossible to manage the 20-30 versioned artifacts that sits in the Merlin (avalon/merlin) structure, and I am working on a single, non-"SNAPSHOT" system, with a single point of update (avalon/merlin/project.xml).
Yell if you object...
Ummmmmmmm....
1. the current approach to versioning is too error-prone
which leads to a conclusions that :(a) we need to simplify
and/or
(b) we need better approaches to maintain version
references 2. moving to a single version IMO is too extreme as we
will loose the differentiation between: (a) product contract
(b) api evolutionHaving thought about this for at least 24 hours, I think we should try and establish a solution that will enable the maintenance of:
1. merlin product version (e.g. 3.3, 3.4, etc.) - encompassing
the cli, unit and xml deployment spec [using final version
semantics]
2. composition version - the api dealing with the meta-model
[using beta-version semantics]
3. runtime - the api dealing with component deploymentWhich kind of brings me back to what we had - but at least refocusing on the subject of figuring out how to manage what we had in a way that makes it drop-dead-easy to maintain version references across systems. I don't know what the solution is but I'm sure the single version is not it.
Cheers, Stephen.
Niclas
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
