Sylvain Wallez wrote:
> 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.
As I wrote on my blog, I think that Cocoon has to change fundamentally
(focus on RESTful services, layered architecture and reuse in every Java
environment) in order to survive in the medium to long term. Staying
with Cocoon 2.x will mostly please already existing users but won't be
very attractive for others.
I wasn't very eager to go for Cocoon 3 at this point of time myself.
Cocoon 3 has been developed completely in the spare time of volunteers
and releasing it will put some pressure on it that I would have liked to
avoid it.
But keeping it in the whiteboard without a release isn't a solution as well.
Cocoon 3 is a chance without a guarantee of success. But it's better
than just waiting for some kind of miracle and doing nothing while
Cocoon and its community are fading away.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
________________________________________________________________________
