Reinhard Pötz wrote:
Cocoon 2.2 already uses cocoon-pipeline-api-1.0.0,
cocoon-sitemap-api-1.0.0., etc.
Yes, I know - this complicates things a little bit.
What concrete name and version number should we use for what we call
corona-pipeline now? cocoon-pipeline-1.0.0 or cocoon-pipeline-2.0.0 Or
do you propose to split up corona-pipeline and corona-sitemap into
api/impl/components like we did in trunk? (NB: I would vote -100 on this
because it just doesn't make sense to split up things into api and impl
modules when there is most probably no second implementation in sight.)
If there is no need to split,we shouldn't. I think the current corona
stuff is a pipeline api so we should call it api :) Even if there are
implementation classes in the package.
Don't you think that this will blur the lines between Cocoon trunk and
the Corona code too much and make it really difficult to understand what
modules can be used together?
Hmm, yes, perhaps - unfortunately we were not good when we introduced
the current 2.2 module names.
Additionally we would carve it in stone that Corona becomes the next
major version of Cocoon. Not that I'm against this in general, but I'm
not sure if it isn't too early for such a decision.
Ok, we have several options: we could use 3.0.0 as version numbers, like
pipeline-api-3.0.0 etc. This makes clear that this stuff is not usable
with all the 2.x versions, but obviously this would create a strong
perception of what would be a Cocoon 3.0.
The other option I see is to use names that 2.2 is currently not using,
like cocoon-pipe, but I don't think that this is a very clear
distinguisher.
Seigh, it's not that easy :( But on the other hand using a fantasy name
doesn't really help either. If we have cocoon-pipeline-api-2.2 and
corona-pipeline-api-1.0 it's as confusing.
The corona stuff is an evolution of 2.2, so I think we should use
functional names with version numbers 3.x and above. Hopefully this pays
off in the long run.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]