cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [M10N] new repo layout
Date Sat, 05 Nov 2005 15:35:03 GMT
Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>> I explained about tags above. For branches it depends, quoting Niclas:
> I understand about tags. Please help me out with branches. Here is 
> current situation, in english:
>   cocoon 2.1 branch depends on cocoon-blocks-xsp 2.1 branch
>   cocoon 2.1 branch depends on cocoon-blocks-forms 1.0 branch
>   cocoon 2.2 branch depends on cocoon-blocks-xsp 2.2 branch
>   cocoon 2.2 branch depends on cocoon-blocks-forms 1.0 branch
>   cocoon 2.2 branch depends on cocoon-blocks-template 1.0 branch
>   cocoon trunk depends on cocoon-blocks-xsp trunk
>   cocoon trunk depends on cocoon-blocks-forms trunk
>   cocoon trunk depends on cocoon-blocks-template trunk
> How this can be translated into the svn directories, in your view? I 
> can see how standard m2 layout handles it, I don't see how your 
> proposed layout can accomodate this.

For 2.1 we should keep it as is and work hard to be able to offer users 
a stable enough 2.2.

After 2.1 should IMO see the core and the various blocks as separate 
projects. So I'm not certain that it will make sense to talk about a 
"cocoon 2.2 branch" anymore. We will rather have a cocoon-core 2.2 and:

  cocoon-xsp 2.2 depends on cocoon-core 2.2 (and some other blocks),

etc, rather than the situation above.

Block development

During block development the block can depend on released versions of 
other blocks. This means that you just need to check out the block you 
want to work with, the rest of the blocks are downloaded from a maven 
repository when you compile. This makes development more stable as 
temporary instabilities in other blocks not will affect your development.

Gump and hopefully automatically executed tests can keep a look at that 
everything still is integratable.

Maybe there is some mechanism in Maven so that you can force it to use 
the current version of all blocks, for those who need to work on several 
blocks in parallell.

Leting a block depend only on released block might seem like a radical 
and possibly overly burocratic way to go. And with our current release 
rate it will obviously not work.

But OTH it will give us motvation for releasing much more often.


When we release a block it must always depend on other released blocks. 
So when we release a block we will also provide a POM that describe its 
dependencies. The blocks can have independent release cycles.

For covenience we will probably have some distributions in different 
sizes that contain blocks that work together. And when we do more 
important improvements of the core we will probably want to release new 
versions of all important blocks as well. That will be the closest we 
get to a "Cocoon 2.2".


> (Note: as soon as 2.2 is out we will have to branch it out for 
> maintenance and continue 2.3/3.0 development in the trunk. Above shows 
> post 2.2 release situation.)

I have written many times about why I think that the current situation 
with parallell work on to branches is a  waste of effort and that it 
delays release of new functionality and decrease the quality of the 
trunk. I will not repeat the arguments here.

So IMO there should not be a maintainamce branch like 2.2.x in the 
future. Neither should there be a trunk that we don't release anything 
from during several years. For blocks like the core and CForms that we 
do a lot of work on we should do a relase from the trunk every 6-8 weeks.

If we for some reason need a bug fix release for an older release, say 
that the latest cocoon core release from the trunk was 2.3.1 and that we 
want to apply some bugfixes to cocoon core 2.2.3. Then we just copy the 
released cocoon-core 2.2.3 to cocoon/branches do the bugfixing and when 
we have finished them we release a new version by moving it back to 
cocoon/releases and name it cocoon-core-2.2.4.

If someone want to introduce new ideas and experiments in the trunk of 
some block and is afraid that it will destabilize the block then a 
temporary branch in the whiteboard is the way to go. As soon as the new 
ideas have been proven to work well enough in the whiteboard, it is time 
to ask the community if it accept to merge it back to the trunk.

                         --- o0o ---

So nearly all work and releases will be from the trunk. Dependencies is 
handled at block level and through Maven. Blocks are supposed to depend 
on released blocks.

Branches are supposed to be short lived. Bug fix branches of old 
releases are put in cocoon/branches and new and unproven ideas are put 
into cocoon/whiteboard.



View raw message