Peter Donald wrote:
>
> So we would like to split the CVS into three separate
> subprojects/subCVSes (jakarta-cornerstone, jakarta-avalon
> and jakarta-phoenix). This would allow us to safely have
> different release schedules and would give a sense of
> stability to those who just want to use the jakarta-avalon
> component. It would also force us to stabilize faster as
> we wouldn't be able to as easily intermingle changes ;)

One thing we discussed immediately prior to the PMC (and therefore not in
the minutes) was the possibility of encouraging the use of directories
instead of propagating multiple trees.  So instead of a jakarta-tomcat-40
and a jakarta-tomcat-41, there would be a jakarta-tomcat with a separate
subdirectory for each release.

With such a structure, one still has the ability to only checkout or update
the portions that you are interested in.

This is not much different than what tomcat-40 or even taglibs are doing
with multiple projects under a single top level directory.

> So in summary what we would like to do is have three
> deliverables within the same project. Namely;
>
> jakarta-avalon (Beta->STABLE)
> jakarta-phoenix (Alpha->Beta)
> jakarta-cornerstone (Alpha)

Given the experience we had with Tomcat, I would discourage you from naming
one of the submodules avalon as there will still be the temptation to refer
to the whole as avalon.

Now, here's a loaded question: which of these is Cocoon2 using?  The reason
that I ask is that when I was trying to get my tinderbox off the ground, I
did not like the answer that the APIs were subject to change without
concern to providing backwards compatibility; and what I really didn't like
was the suggestion that Cocoon2 not track to the changes.

- Sam Ruby


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to