cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruning up the CVS tree for real)
Date Thu, 27 Feb 2003 12:26:06 GMT
On 27/2/03 11:39, "Gianugo Rabellino" <gianugo@apache.org> wrote:

>> - Create a new repository called "cocoon-2.0" and copy over the cocoon-2_0_5
>>   branch of "xml-cocoon2" (clean checkout, and re-import)
>>     (this has been created as a part of this proposal, and it contains what
>>     it should. All files are down at version 1.1 in this repository)
> 
> +1. But what happens from there on? No more branching, I assume, just
> tagging as 2.0.x release happens. Right?

Yessir! :-) That would be just fantastic...

>> - Create a new repository called "cocoon-2.1" and copy over head from the
>>   main "xml-cocoon2" repository (clean checkout, and re-import)
>>     (this has been created as a part of this proposal, and it contains what
>>     it should. All files are down at version 1.1 in this repository)
> 
> Here I'm not sure. ATM I'd rather have the latest cocoon version in a
> repository such as plain "cocoon" (think CVS HEAD). In this Cocoon
> lifecycle it represents 2.1. When we release 2.1, we can move this repo
> to cocoon-2.1 and start using it (with tagging, no branching) for 2.1.x
> releases, while "cocoon" would become the 2.2 repo. Isn't it cleaner
> from a logical POV?

That's a good idea... How about if we keep the module symlinked... So,
"cocoon" is the current copy, which is a symlink to whatever is the current
version "cocoon-2.1" now, "cocoon-2.2" "cocoon-3.0" and so on in the
future...

    Pier



Mime
View raw message