On 27/2/03 11:39, "Gianugo Rabellino" <[EMAIL PROTECTED]> 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
