cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Versioning of blocks
Date Mon, 09 Jan 2006 09:39:02 GMT
Carsten Ziegeler wrote:

>Jorg Heymans wrote:
>>Carsten Ziegeler wrote:
>>>Hmm, yes, like I wrote in my latest answer to Daniels post, I'm not sure
>>>if this is the right approach. I think, blocks will be totally
>>>independent wrt to releases/versioning from the core in the future. And
>>Yes the release cycle of blocks will be totally independent of the core
>>release cycle. The actual versioning is independent as well.
>>The fact that my suggestion copies ./trunk to ./branch does not mean
>>that we tie the release or versioning of blocks in ./branch to that
>>core. It just means that we explicitly state that those blocks are only
>>guaranteed to be working with that particular core. The branch would
>>effectively be in maintenance mode, meaning you'ld only backport
>>*critical* bugfixes.
>Hmm, ok, sorry it must be the early time of the year that I don't get it :(
>I'll try to repeat what I understood so far with an example. Assume we
>have the core and three blocks, A, B and C. For simplification we start
>all blocks with 1.0 while the core gets version 2.2:
>+ trunk
>    + core (2.2)
>    + block A (1.0)
>    + block B (1.0)
>    + block C (1.0)
>Now, we release everything and continue development (tagging is imho not
>an issue, so I'll leave that out):
>+ trunk
>    + core (2.3)
>    + block A (1.1)
>    + block B (1.1)
>    + block C (1.1)
>So far everything is fine - now, we need a bug fix for 2.2, so we create
>a branch (from the first release?). We name the branch 2.2.x:
>+ branches
>  + 2.2.x
>    + core (2.2.x)
>    + block A (1.0)
>    + block B (1.0)
>    + block C (1.0)
No need to branch block A, B and C. With maven all dependencies are 
declared in the POM. And when releasing a block or a set of block we 
should require that they depend on other released blocks. So the 
core-2.2 will have explicit dependencies on block-1.0 etc that are 
available in the repository.

>Now at this time, we only need a branch for the core as we only need a
>bug fix for core, but not for the blocks. So branching the whole trunk
>is not the right way. So I guess that you suggest to just branch the
>core in this case?
>+ branches
>   + 2.2.x
>      + core (2.2.1)
Yes, would rather use
+ branches
  + core-2.2.1

as I don't see that the 2.2.x makes any sense. When the bug is fixed, we 
release and just move core-2.2.1 to the release folder. No need to have 
any copy in the branch folder anymore.

>So, this would mean that all blocks in trunk are always related to the
>core version. If you want to do a maintenance release for a block, you
>create a branch under the core-version the maintenance release is
>targetted at?
>+ branches
>   + 2.2.x
>      + core (2.2.1)
>      + block B (1.0.1)
+ branches
  + blockB-1.0.1

The POM of blockB-1.0.1 have a dependency of the released version 
core-2.2.1, so there is no need to have a branch of the core.

>Is it this what you mean or did I get it totally wrong :)
You got it right.

                        --- o0o ---

With M2 the directory structure of the SVN repository have much less 
importance as all dependencies are handles through POMs. You can as an 
example just check out trunk/cocoon-session-fw/cocoon-session-fw-sample 
and work on it independently. It will use the most current snapshots of 
cocoon-core and cocoon-session-fw from our snapshot repository.

The only importance of the "global" directory structure of the SVN is 
that if we have a number of projects that many people in the community 
are likely to want to have checked out, it is more practical to have 
these in the same SVN folder (trunk) so that you just can check out the 
whole folder. For the trunk we can also have a common POM that builds 
all the projects in the trunk.

A "higher" level POM have two different responsibilities: it has a list 
of sub projects that it build recursively and it contain common 
definitions for the sub projects. Sub projects can refer to the "higher" 
level POM as parent POM. IIUC the subprojects only reuse the 
commondefinitions and not the list of sibling projects. To keep sub 
projects as independent as possible, the parent POM should only contain 
definitions that are likely to be stable over time, like repository 
references. It should be mentioned though that the parent POMs also are 
versioned and put in the repository so a project in a sub folder can 
referer to an earlier version of the parent POM if necessary.

But building all projects at once will be much less important with M2 as 
all sub projects can be build independently and use dependencies from 
the snapshot repository.

                        --- o0o ---

For the scenario you mentioned in an earlier mail where some but not all 
blocks in the trunk is compatible with the cocoon-core in trunk, only 
the ones that are compatible with core and compiles together are listed 
in the module list in the trunk level POM. The blocks that isn't 
compatible with the cocoon-core in trunk, just refer to an earlier 
version of cocoon-core in their dependency list, and possibly an earlier 
version of the parent POM.

Now, this kind of problems mainly depend on the fact that we have weak 
contracts between blocks and between core and the rest of the blocks. 
And also because the core is far to "fat". With M2 it is much easier to 
handle build system and dependency issues. So we can start to split the 
core into much smaller parts and strenghten the contracts. By doing 
this, most of the issues with complicated and unclear interdependencies 
will disapear.


View raw message