Reinhard Pötz wrote:
> 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.
I meant "releasing it as 'Cocoon 3'' will put ...
> 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]
________________________________________________________________________
