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)
Rather,
+ 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.
/Daniel
