cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: A new name for Corona (take 2)
Date Mon, 04 Aug 2008 16:43:05 GMT
Pick a number that will never be production for the experimental
branch e.g. 2.7.  Skip a few numbers in case trunk needs another minor
number (e.g. 2.3 and 2.4) and to avoid confusion that this branch is
not the immediate successor to 2.2.  Do not use 2.9 in case a
non-Corona pre-release branch is needed before 3.0.

A number both distinguishes code compatibility and suggests the
position in history better than a code name such as x.
"cocoon-2.7-pipeline" is obviously not compatible with Cocoon-2.2 or
Cocoon-3.0.  This also handles all possible futures:
- The number suggests that the code becomes obsolete after 3.0 is
released if the branch becomes 3.0 or is abandoned;
cocoon-x-pipeline-1.0 does not.
- The branch could become NewName-1.0 if the projects split.

The Lenya project did this twice:
- Production 1.2 branched to 1.4 for development of 2.0.
- An experimental branch based on 1.2 incompatible with 1.4 was named 1.3.


On 8/4/08, Carsten Ziegeler <> wrote:
> 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 Ziegeler
View raw message