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.
Releases
========
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".
Branches
========
(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.
WDYT?
/Daniel
