Renaming Corona to Cocoon 3.0 and infrastructure [version 2]
After our recent discussions, here is my reworked proposal:
Versioning
---
Cocoon 3 will follow the alpha/beta/rc release scheme (like Mozilla,
Maven, Apache Commons, etc.). The first release will be 3.0-alpha-1.
This will be a clear marker that is already visible when you add Cocoon
as a dependency to your build or download the artifacts manually.
Additionally all release artifacts will contain a warning message and an
explanation what alpha means.
SVN
---
In order to make the life easier for people who use git-svn, I propose
to use the standard SVN directory structure:
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk
http://svn.apache.org/repos/asf/cocoon/cocoon3/tags
Maven
---
We use functional names for all artifacts:
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.
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
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, I propose
http://apache.org/cocoon/sitemap
http://apache.org/cocoon/servlet
http://apache.org/cocoon/controller
JIRA
---
I propose the creation of a COCOON3 project so that Cocoon 2.x and
Cocoon 3 issues don't get mixed up.
CI
---
Apache Infrastructure offers a managed Hudson instance. I propose to
setup a Cocoon 3 project there.
- o -
Any further comments? If there aren't any objections, I will start with
the renaming process next week.
Or do I need a vote before? If so I will start the voting process asap.
Any opinions?
--
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]
Re: Renaming Corona to Cocoon 3.0 and infrastructure [version 2]
On Wed, Aug 20, 2008 at 7:44 AM, Reinhard Pötz [EMAIL PROTECTED] wrote: After our recent discussions, here is my reworked proposal: snipGood looking proposal/snip Or do I need a vote before? If so I will start the voting process asap. Any opinions? I think you should run a vote, if only for completeness. I don't see anything controversial (other than the already discussed 3.0 issue) so I'd imagine it should be straight forward enough. -- Peter Hunsberger
Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Hi Jeremy, Jeremy Quinn pisze: From the PoV of users, it should also be clear : If you want or have to use Ant, use 2.1 If you want or have to use Maven, use 2.2 If you just need the Pipeline API, use 3.0 I'm not sure if I get you here correctly so I'll ask: Do you express your own wish or your own perception of situation we have when it comes to differences between 2.1 and 2.2? There should be no other difference in quality between the release versions, and none should be implied. I'm afraid that it's not a case for some time at least according to my understand of Cocoon 2.2. -- Best regards, Grzegorz Kossakowski
Re: Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Hi Grzegorz, Many thanks for your response : ) On 19 Aug 2008, at 12:54, Grzegorz Kossakowski wrote: Hi Jeremy, Jeremy Quinn pisze: From the PoV of users, it should also be clear : If you want or have to use Ant, use 2.1 If you want or have to use Maven, use 2.2 If you just need the Pipeline API, use 3.0 I'm not sure if I get you here correctly so I'll ask: Do you express your own wish or your own perception of situation we have when it comes to differences between 2.1 and 2.2? I am trying to think about this from a 'marketing' perspective. It would be typical to assume (IMHO) that 3.0 is somehow better than 2.2 which is somehow better than 2.1, just because of the version numbers. Whereas from the point of view of a User, making projects (using SiteMaps, XML, XSLT, JXTemplate, FlowScript, etc. etc.) 2.1 and 2.2 are as much as possible, completely compatible and mostly just as capable as each other. The fact that once a User has a suitable build, it makes very little difference whether they use 2.1 or 2.2 (not sure about 3.0) is something that I think we should put across more clearly. It would be a shame to loose potential Users, because they perceived that the version that used their preferred build-technology, was in some way obsolete (which could now happen with both 2.1 and 2.2). Maybe a capability matrix of some sort, would help a User trying to decide which version to use, would provide more reassurance that the 3 versions (or at least 2.1 and 2.2) would provide a viable, stable, long-lasting platform, even though the version numbers may say otherwise. There should be no other difference in quality between the release versions, and none should be implied. I'm afraid that it's not a case for some time at least according to my understand of Cocoon 2.2. The build and distribution system for 2.2 is clearly more modern and sophisticated. It has a polymorphic block paradigm that suits the build technology, it has the powerful concept of virtual pipelines etc. etc. And this is all great ! But from the Users' PoV of making projects, I cannot imagine a project that could be made successfully with 2.2 that could not be made using 2.1 (don't know enough about 3.0). My assumption is that you personally find 2.2 more powerful because you prefer the build technology, not because 2.2 is intrinsically more powerful, or less buggy. This is why I propose that we should give a clear message that all release versions are valid choices, primarily dependant on the build- technology that you prefer, not on specific version numbers. AFAIU, TomCat is in a similar situation, where the different primary versions, represent not quality, but the version of the ServletAPI and JSP Spec they support. see: http://tomcat.apache.org/whichversion.html I hope this is clearer best regards Jeremy
Re: Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Just an added note On 19 Aug 2008, at 16:04, Jeremy Quinn wrote: It would be typical to assume (IMHO) that 3.0 is somehow better than 2.2 which is somehow better than 2.1, just because of the version numbers. This assumption is so easy to make, because for instance : 2.1 was better than 2.0 which was MUCH better than 1.0 etc. But now, we seem to use version numbers differently. regards Jeremy
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Sylvain Wallez pisze: 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. Yes, that makes sense. I also wonder how beta, RC, etc. releases can be more confusing that odd/even versioning. 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. Provided that one documents our thoughts on 2.2 and 3.0 clearly I don't think there will be that much of confusion. Actually, I think it's a high time for us to define official document that explains our rules for giving artifacts version numbers. WDYT? 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. Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's trunk? I can understand that people were fed up with Maven at the beginning of the transition because it was almost impossible to build Cocoon. But that was more than one year ago. When it comes to user community, I would say that it grows quite nicely. There are people contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2. Could it be a good idea that old-timers just take an example of our user's community and overcome their own prejudices, finally? [1] http://article.gmane.org/gmane.text.xml.cocoon.user/65605 [2] http://thread.gmane.org/gmane.text.xml.cocoon.user/65389/focus=65416 -- Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Grzegorz Kossakowski pisze: 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. Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's trunk? I can understand that people were fed up with Maven at the beginning of the transition because it was almost impossible to build Cocoon. But that was more than one year ago. When it comes to user community, I would say that it grows quite nicely. There are people contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2. Could it be a good idea that old-timers just take an example of our user's community and overcome their own prejudices, finally? I realized that I little bit misunderstood Sylvain's e-mail and used inappropriate tone for my response. The last statement was not really needed. I'm sorry about that, Sylvain. -- Best regards, Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Just another 0.01€ in the same direction: most developing users (esp. the ones developing cocoon itself) would qualify as hackers. Those are used to associate special meanings with groups of version numbers as a number of other projects follow similar rules (e.g. Linux for long used that even/odd numbering scheme). However, as Cocoon will (and should) attract non hacker users, on a first view, what will indicate to them, that version 3.1.2 is not superior to 3.0.9? (superior aka later or more mature) While I personally am quite fine with any versioning scheme, I do think, it is absolutely necessary to have a policy document explaining it to accidental users. And this nearly at the same time they will detect something like cocoon does exist at all. Rainer Sylvain Wallez schrieb: 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. 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. My 0.02 euros. Sylvain
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Dear Grzegorz I was just in the process of flaming the bejesus out of you for what you just said! Without a whole bunch of very smart 'old-timers' like Sylvain, there would be no Cocoon. The Ant versus Maven controversy has already caused too much disaffection in this project, IMHO. Thanks for retracting/apologising so quickly. regards Jeremy On 18 Aug 2008, at 11:05, Grzegorz Kossakowski wrote: Grzegorz Kossakowski pisze: 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. Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's trunk? I can understand that people were fed up with Maven at the beginning of the transition because it was almost impossible to build Cocoon. But that was more than one year ago. When it comes to user community, I would say that it grows quite nicely. There are people contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2. Could it be a good idea that old-timers just take an example of our user's community and overcome their own prejudices, finally? I realized that I little bit misunderstood Sylvain's e-mail and used inappropriate tone for my response. The last statement was not really needed. I'm sorry about that, Sylvain. -- Best regards, Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Dear All On 17 Aug 2008, at 18:41, Sylvain Wallez wrote: 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. Many thanks Sylvain for taking the time to voice your opinion. I too missed the vote for the same reason. I too worry about the message being sent here, as a community there are many still smarting from the difficult transition from 2.1 to 2.2 and whether that perception is right or wrong, without community support, this project is dogmeat. While I think a Pipeline etc. API is a brilliant idea, I have doubts that calling it Cocoon 3.0 is the right move, right now. I am too late obviously, the democratic process has taken place, but TBH, reading the C3 site and Reinhard's blog post (sorry Reinhard) left me feeling that we were throwing out the baby with the bathwater. Leaving the difficult and controversial issue of Ant versus Maven aside (Sylvain had good reasons to publicly repudiate Maven, when he did) IMHO all release versions of Cocoon still have relevance : Cocoon 2.1 for Ant fanciers Cocoon 2.2 for Maven mavens Cocoon 3.0 for integrators But I am wondering where 3.0 goes? How does it grow, what true innovations are being thrown away? I do not mean to be sending a negative message, it is important that Cocoon continues to innovate and attract new talent. But we should be very careful in the message we give. 2.2 is only 'better' than 2.1 (etc.) if you prefer Maven over Ant, we should not be putting out the message that somehow 2.1 (and now 2.2) is somehow obsolete. It is just a matter of taste and circumstance, IMHO. regards Jeremy
Re: Renaming Corona to Cocoon 3.0 and infrastructure
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.
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.
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.
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.
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.
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.
--
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]
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Grzegorz Kossakowski wrote: Sylvain Wallez pisze: 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. Yes, that makes sense. I also wonder how beta, RC, etc. releases can be more confusing that odd/even versioning. 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. Provided that one documents our thoughts on 2.2 and 3.0 clearly I don't think there will be that much of confusion. Actually, I think it's a high time for us to define official document that explains our rules for giving artifacts version numbers. WDYT? 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. Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's trunk? I can understand that people were fed up with Maven at the beginning of the transition because it was almost impossible to build Cocoon. But that was more than one year ago. I can't say what problems there are _now_ since I don't build Cocoon anymore. Hopefully it works now, and I was referring to the past: when the move to Maven was started, the 2.2 build was mostly broken for months, which drained an incredible amount of energy away from the project, either because people got discouraged by this broken build (e.g. me), or because they invested their volunteer time in understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon. I'm glad it seems to work now, but the amount of energy needed to setup and maintain this build system (remember, it's _just_ a build system) has been astronomical. When it comes to user community, I would say that it grows quite nicely. There are people contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2. It's very nice to see people using 2.2, but I have the impression that most of the 2.2-related questions are related to maven-isms, artifacts, poms, etc. Without wanting to sound harsh, I'm wondering whether this community has learned to live over time with some sort of chronic disease, and is so used to it now that it doesn't even realize that life could be easier without it. Note that I said could and not would since ultimately the people-that-do decide what they prefer. And yes I'm a retired old-timer here, but I still care for this community where I learned so much. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Grzegorz Kossakowski wrote: Grzegorz Kossakowski pisze: 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. Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's trunk? I can understand that people were fed up with Maven at the beginning of the transition because it was almost impossible to build Cocoon. But that was more than one year ago. When it comes to user community, I would say that it grows quite nicely. There are people contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2. Could it be a good idea that old-timers just take an example of our user's community and overcome their own prejudices, finally? I realized that I little bit misunderstood Sylvain's e-mail and used inappropriate tone for my response. The last statement was not really needed. I'm sorry about that, Sylvain. No worries. I was actually trying to understand what you really meant :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
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. Great! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
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
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Sylvain Wallez pisze: I can't say what problems there are _now_ since I don't build Cocoon anymore. Hopefully it works now, and I was referring to the past: when the move to Maven was started, the 2.2 build was mostly broken for months, which drained an incredible amount of energy away from the project, either because people got discouraged by this broken build (e.g. me), or because they invested their volunteer time in understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon. I'm glad it seems to work now, but the amount of energy needed to setup and maintain this build system (remember, it's _just_ a build system) has been astronomical. I've been working with Maven (mainly when working with Cocoon) for more than year and I can agree on main point of Maven critics that Maven is flawed. My personal opinion is that basic ideas behind Maven are correct but implementation is totally broken. Or at least it was at the beginning because now, thanks to many eye balls, it seems to improve from release to release. I was wondering many times if there is any other choice for us. Given the amount energy we've put into mavenization process any switch is impossible so such discussion could be only theoretical. Still I would enjoy reading about some alternatives because this could put my (and probably others) thinking into right direction thus, eventually improving our existing infrastructure. There is one statement that I don't agree: Maven is not just a build system. If it was only a build system I would be the first one to propose dropping Maven completely because of its implementation. For me, Maven is the whole ecosystem which consists of good practices when it comes to your project's structure, Maven repository (the killer feature IMHO) and integration with so many systems acting around basic build process. What I would prefer is to take a lesson from our past experience but still focus on the future. I strongly believe that we have reached this stage when people can happily focus on developing Cocoon and not on developing Cocoon's infrastructure thus I would like to invite all old-timers to join our forces and provide the best of Cocoon experience ever. I strongly believe we have all foundations needed for that now. It's very nice to see people using 2.2, but I have the impression that most of the 2.2-related questions are related to maven-isms, artifacts, poms, etc. Without wanting to sound harsh, I'm wondering whether this community has learned to live over time with some sort of chronic disease, and is so used to it now that it doesn't even realize that life could be easier without it. Most of these questions come from the confusion about splitting up Cocoon into smaller pieces. And even more questions come from the fact that people starting with 2.2 are still trying to build it themselves because that was done in 2.1. If you use released versions then you will have no problem with dependencies, missing artifacts, etc. When you checkout trunk and try to build it then I would say that it should be no surprise that sometimes you get into troubles, right? I would really like to know what kind of chronic disease you see Sylvain. I don't deny there might be one so if you would have shared your observations with rest community we could start to think about improving it in the future. Note that I said could and not would since ultimately the people-that-do decide what they prefer. And yes I'm a retired old-timer here, but I still care for this community where I learned so much. For me it would be interesting to see if one of retired old-timers could try to spend some time on playing with trunk just to gather some experience. Certainly, such external audit by some of the most honored members of this community would be a blessing experience only if it would allow to bring closer our stances. -- Best regards, Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Reinhard Pötz pisze: 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. Even if I'm still busy with supporting community with 2.2 transition so I have no time to work on Corona/3.0 I wholeheartedly support Reinhard's position. -- Best regards, Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
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
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Grzegorz Kossakowski wrote: Sylvain Wallez pisze: I can't say what problems there are _now_ since I don't build Cocoon anymore. Hopefully it works now, and I was referring to the past: when the move to Maven was started, the 2.2 build was mostly broken for months, which drained an incredible amount of energy away from the project, either because people got discouraged by this broken build (e.g. me), or because they invested their volunteer time in understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon. I'm glad it seems to work now, but the amount of energy needed to setup and maintain this build system (remember, it's _just_ a build system) has been astronomical. I've been working with Maven (mainly when working with Cocoon) for more than year and I can agree on main point of Maven critics that Maven is flawed. My personal opinion is that basic ideas behind Maven are correct but implementation is totally broken. Or at least it was at the beginning because now, thanks to many eye balls, it seems to improve from release to release. I was wondering many times if there is any other choice for us. Given the amount energy we've put into mavenization process any switch is impossible so such discussion could be only theoretical. Still I would enjoy reading about some alternatives because this could put my (and probably others) thinking into right direction thus, eventually improving our existing infrastructure. This isn't theoretical at all. Use Ant+Ivy (http://ant.apache.org/ivy/) and you have something that doesn't rely on undocumented declarative black magic (the various plugins you add to your pom.xml), doesn't require you to write your own plugins (or tasks as they're called in Ant) and gives you line-precise error reporting when something goes wrong. There is one statement that I don't agree: Maven is not just a build system. If it was only a build system I would be the first one to propose dropping Maven completely because of its implementation. For me, Maven is the whole ecosystem which consists of good practices when it comes to your project's structure, Maven repository (the killer feature IMHO) and integration with so many systems acting around basic build process. Ivy for your artifacts management. It does it well, and can use Maven repositories. I've been using it happily for more than 2 years now on rather big projects (after having banged my head on Maven). What I would prefer is to take a lesson from our past experience but still focus on the future. I strongly believe that we have reached this stage when people can happily focus on developing Cocoon and not on developing Cocoon's infrastructure thus I would like to invite all old-timers to join our forces and provide the best of Cocoon experience ever. I strongly believe we have all foundations needed for that now. And this leads to another question, which Reinhard outlined in his latest blog post, and Stefano did years ago: what's the purpose of Cocoon in today's technology landscape? It used to be a great you can do everything with it solution, but these days are over. There are some very nice webapp component frameworks like Wicket or GWT, there are ESBs that do pipelined transformations like Mule or ServiceMix, and XML is no more the only mainstream interchange language with the success of JSON and the emergence of binary formats like Thrift or Google Buffers. Cocoon therefore has to be rethought as a toolbox for those domains where it has no equivalent, and find new domains where it can innovate, and Corona (or whatever its name) certainly goes in the right direction. Pipelines are among the existing distinctive features of Cocoon, and also REST-ish pattern matching although many frameworks are now REST-friendly. It's very nice to see people using 2.2, but I have the impression that most of the 2.2-related questions are related to maven-isms, artifacts, poms, etc. Without wanting to sound harsh, I'm wondering whether this community has learned to live over time with some sort of chronic disease, and is so used to it now that it doesn't even realize that life could be easier without it. Most of these questions come from the confusion about splitting up Cocoon into smaller pieces. And even more questions come from the fact that people starting with 2.2 are still trying to build it themselves because that was done in 2.1. If you use released versions then you will have no problem with dependencies, missing artifacts, etc. When you checkout trunk and try to build it then I would say that it should be no surprise that sometimes you get into troubles, right? The build should fail only if there are some bugs in Cocoon's code (compilation issues or failed tests) or if some artifacts are missing from your cache and remote repositories aren't available (BTW this what just happened to me: there's a compilation failure in cocoon-core). I would really
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Sylvain Wallez wrote: By chronic disease, I was referring to Maven. And it's not specific to Cocoon, but to many other projects. Maven has brought one new brillant idea to the Java world, which is artifact repositories (note though that Linux repositories have existed for a very long time). But using Maven requires to adhere to the whole thing: repository management, which is good, but also a declarative under-documented build system. And Maven is also self-updating, which is a nice idea on paper but means the buid is not repeatable since you don't know what is used to build your system. Wow. I guess you don't like Maven. There are other alternatives to your complaints - like becoming a committer there and fixing them. Using Ant + Ivy has all the downfalls of GNU Make. Instead of one undocumented (not sure where you get that from) build system you end up with every build system being different and usually, mostly undocumented. As for the self-updating, dependency management allows you to have complete control over the artifacts you wish to use. My contribution to Maven has to continue to make that aspect better. Ralph
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Please, let's not get into the usual maven bashing threads. I'm tired of reading all the love and hate about maven over and over again. If someone thinks that the current system sucks *and* has time to try out new things, great. If not, let's keep the working system. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Hi Carsten On 18 Aug 2008, at 16:41, Carsten Ziegeler wrote: Please, let's not get into the usual maven bashing threads. I'm tired of reading all the love and hate about maven over and over again. If someone thinks that the current system sucks *and* has time to try out new things, great. If not, let's keep the working system. I agree 100% and apologise if I helped raise it again . What you stated, I think is the correct PoV for Cocoon developers. From the PoV of users, it should also be clear : If you want or have to use Ant, use 2.1 If you want or have to use Maven, use 2.2 If you just need the Pipeline API, use 3.0 There should be no other difference in quality between the release versions, and none should be implied. best regards Jeremy
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Ralph Goers wrote: Sylvain Wallez wrote: By chronic disease, I was referring to Maven. And it's not specific to Cocoon, but to many other projects. Maven has brought one new brillant idea to the Java world, which is artifact repositories (note though that Linux repositories have existed for a very long time). But using Maven requires to adhere to the whole thing: repository management, which is good, but also a declarative under-documented build system. And Maven is also self-updating, which is a nice idea on paper but means the buid is not repeatable since you don't know what is used to build your system. Wow. I guess you don't like Maven. There are other alternatives to your complaints - like becoming a committer there and fixing them. That is exactly what I wanted to point out with the Maven sucked too much energy from Cocoon argument: I don't want and shouldn't have to become a committer on the build system as a necessary preliminary to doing usefull stuff on Cocoon. Using Ant + Ivy has all the downfalls of GNU Make. Instead of one undocumented (not sure where you get that from) build system you end up with every build system being different and usually, mostly undocumented. Most of the Maven plugins can be rewritten in a couple of Ant lines. Also, it is possible to have common reusable Ant build files that avoid rewriting everything from scratch every time. Now it's true that no community effort has taken place to provide a distribution of such standard reusable Ant files. Maybe people did not felt the urge to do so because Ant files to build simple artifacts are so straightforward. As for the self-updating, dependency management allows you to have complete control over the artifacts you wish to use. My contribution to Maven has to continue to make that aspect better. I now this is work in progress. But not self-updating should be the default rather than being an intial feature that can be disabled by specifying the exact version of each and every Maven plugin you want a fixed-version of (and how do I know which version I want?) Now I'll shut up since most people here seem to be happy with Maven. I'm not, let's move on to other debates. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
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
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Grzegorz Kossakowski wrote:
Reinhard Pötz pisze:
snip/
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.
I have no strong opinion on this. If this works better with git, I'm
fine with your proposal.
snip/
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?
Unlike Continuum, I've never had any problems with Hudson. IMO it's also
more intuitive and makes it easy to configure any Maven/JDK combination.
And, it is also smart because it automatically detects upstream and
downstream projects by analyzing the POM structure.
Also Jason seems to be a Hudson fan
(http://maven.markmail.org/message/q6thc63lzby23d5h)
--
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]
Re: Renaming Corona to Cocoon 3.0 and infrastructure
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. 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. My 0.02 euros. Sylvain -- Sylvain Wallez - http://bluxte.net
Renaming Corona to Cocoon 3.0 and infrastructure
Reinhard Pötz wrote:
Reinhard Pötz wrote:
Following the result of our recent discussion about the future of
Corona, I propose Corona to become Cocoon 3.
This means that any reference on Corona in source files, package
names, artifact ids, group ids or anywhere else will be dropped and
the standard Cocoon namespace org.apache.cocoon will be used.
This majority vote stays open for 72 hours.
Please cast your votes.
Here is my +1
During the voting period there were 12 +1 votes and one negative one.
This means that the proposal was accepted.
For further discussion I will be sending a message to this list that
describes proposed changes (package name changes, groupId/artifactId,
versioning, Jira, SVN move, etc.).
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.
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.
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.
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
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
JIRA
---
I propose the creation of a COCOON3 project so that Cocoon 2.x and
Cocoon 3 issues don't get mixed up.
CI
---
Apache Infrastructure offers a managed Hudson instance. I propose to
setup a Cocoon 3 project there.
Any comments?
--
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]
Re: Renaming Corona to Cocoon 3.0 and infrastructure
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. +1 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. Why wouldn't you use http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3.0.x? Then create 3.1.x when it is time for that. Presumably you will create a 3.2.x shortly after that so you can do bug fixes only on 3.1.x and new development on 3.2.x. If not, then I'm not sure what the point of the numbering scheme is. I'm OK with the rest of the proposal.
