cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Renaming Corona to Cocoon 3.0 and infrastructure
Date Mon, 18 Aug 2008 12:47:23 GMT
Reinhard Pötz wrote:
> Sylvain Wallez wrote:
>> Reinhard Pötz wrote:
>>> 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 would say the contrary. Let's not forget that most of our users aren't
>> hard-core developers (they love Cocoon because they can do complex stuff
>> without programming) and they aren't used to this odd/even versioning
>> scheme that comes from the Linux kernel.
>> Rather than that, it seems to me that most of the "normal" (i.e. non
>> hard-core hacker) people consider a version without any "beta",
>> "milestone" or other suffix as an official stable release. A well-known
>> example is Firefox that goes through a series of milestones, beta and RC
>> version before releasing a stable version with the same number. Eclipse
>> does the same.
> I don't have a strong opinion on this, except that I don't think that
> the term milestone doesn't fit very well for us because this would imply
> that we have like e.g. Eclipse a well-defined roadmap. And as we all
> know, that's simply not the case.

Well, although there's no formal roadmaps, there are "big features" that 
more or less define it, isn't it?

> I'm also fine with 3.0-alpha-1, etc. and, see the reasons below, it's
> probably better to change the proposal into this direction.
>> Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on
>> vacation, but I really think this is too early. Cocoon 2.2 is just out
>> and we announce a 3.0. This will most probably lead people to consider
>> 2.2 as a transition to 3.0 and just not use it, and thus just look
>> elsewhere. Stated clearly, I have fears that just as Maven almost killed
>> the developer community for 2.2, announcing a 3.0 now will kill the user
>> community.
> We had three possible routes for Corona:
>  1) Develop Corona outside of the Cocoon project (e.g. Google,
>     Sourceforge, etc.)
>  2) Find some alternative name and release it under this codename.
>  3) Release it as Cocoon 3.0-alpha-x
> 1) would have been really dangerous IMO. What would people have thought
> if the former PMC chair created an alternative project that is a
> reimplementation of Cocoon outside of the oversight of the Cocoon PMC.
> And that just a few months after his resignation.

I totally agree with this, and Apache has the necessary rules and 
infrastructure to host experiments/rewrites/revolutions under the 
project's umbrella.

> 2) Many people advised not to invent another codename. Also the name
> finding game wasn't really successful. Personally I'm not willing to
> invest any more time into this.

I don't think there's even a need to play the name game: if the 
experiment/rewrite/revolution is successful, it just takes over the main 
branch (e.g. Catalina that has replaced Tomcat) and otherwise it just 
dies and vanishes.

> 3) Releasing 3.0 comes with the risk that 3.0 never takes off and
> doesn't attract a broader developer and user community. But as long as
> we only release alpha software, we can even do a re-rewrite.

Not sure I follow you here, and how 3.0 or any other name prevents a 
rewrite as long as there hasn't been any stable release. Now if there is 
an ongoing effort on something named "3.0" and suddenly this thing is 
rewritten, this is likely to be interpreted by the community as "we 
don't really know where we're going" which not a good thing.

> Regarding your "too early announced" argument, I'm not so pessimistic.
> Most people very well understand the difference between production
> quality and alpha software and that alpha software is no guarantee for
> anything (time, quality/stability, community). Addtionally we will add
> warnings to all download pages, READMEs and also adding "alpha" helps.
> Also other projects demonstrate that having an alpha branch doesn't make
> most people wait for the final release of the alpha branch (see Tomcat,
> Jetty, Maven,  httpd, etc.). And if you have time to wait, I don't think
> that you really have to solve a problem.

I hope you're right.

> Additionally we have taken care that Cocoon 2.2 can be run in parallel
> with Cocoon 3.0 in the same web application and they can event
> communicate via the Servlet-Service framework with each other.



Sylvain Wallez -

View raw message