cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Renaming Corona to Cocoon 3.0 and infrastructure
Date Sun, 17 Aug 2008 14:44:36 GMT
Reinhard Pötz pisze:
> Versioning
> -------------------------------
> For Cocoon 2 there have been proposals that all odd versions are
> development/alpha versions and all even versions are stable releases.
> 
> I like this idea and propose that we follow this versioning schema in
> Cocoon 3: All 3.0.x releases are marked as development versions and we
> clearly explain this on the website and the READMEs of all artifacts.
> 
> When we believe that the community and the technology are stable, we do
> a 3.1.0 release.
> 
> I think this is less confusing than appending alpha, beta or milestone
> postfixes.

I have mixed feelings about that but won't block anything.

> SVN
> -------------------------------
> I'm not sure about the new location in SVN. One option I can think of is
> http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk, the other is
> http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3
> 
> I slightly prefer http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk.

Hmmm. What about http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk (and possibly tags,
branches 
as well in future)?

For me repository layout is rather important since I'm using Git to access our Subversion
repository 
and I don't want to make it confused by all these non-standard layouts.

> Maven
> -------------------------------
> We've already discussed this and the outcome was that we prefer
> functional names:
> 
> org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
> org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
> org.apache.cocoon.servlet:cocoon-servlet:3.0.0
> org.apache.cocoon.controller:cocoon-controller:3.0.0
> org.apache.cocoon.rest:cocoon-rest:3.0.0
> org.apache.cocoon.stringtemplate:cocoon-stringtemplate:3.0.0
> 
> By using the functional name as part of the groupId, Cocoon 2.2 and
> Cocoon 3 can be used together without getting any problems with the
> dependency resolution mechanisms of Maven or Ivy.

+1

> JAVA NAMESPACES
> -------------------------------
> Coocon 3 will use the "org.apache.cocoon" namespace. The sub-packages
> are reserved for functional names:
> 
>  org.apache.cocoon.pipeline
>  org.apache.cocoon.sitemap
>  org.apache.cocoon.servlet
>  org.apache.cocoon.controller
>  org.apache.cocoon.rest
>  org.apache.cocoon.stringtemplate

+1

> XML NAMESPACES
> -------------------------------
> Corona currently uses three different namespaces in XML documents:
> 
>  http://apache.org/cocoon/corona/sitemap
>  http://apache.org/cocoon/corona/servlet
>  http://apache.org/cocoon/corona/controller
> 
> These namespaces are without a version number.
> 
> Since I don't see how version numbers could help us, I propose
> 
>  http://apache.org/cocoon/sitemap
>  http://apache.org/cocoon/servlet
>  http://apache.org/cocoon/controller

Again, mixed feelings but have no strong opinion here as well.

> JIRA
> -------------------------------
> I propose the creation of a COCOON3 project so that Cocoon 2.x and
> Cocoon 3 issues don't get mixed up.

+1

> CI
> -------------------------------
> Apache Infrastructure offers a managed Hudson instance. I propose to
> setup a Cocoon 3 project there.

Why Hudson instead of Continuum?

Is Hudson more flexible or has a better performance? Or just personal preference?

-- 
Grzegorz Kossakowski

Mime
View raw message