[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [M10N] new repo layout
From:       Jorg Heymans <jh () domek ! be>
Date:       2005-11-05 18:25:09
Message-ID: dkite1$kda$1 () sea ! gmane ! org
[Download RAW message or body]


Daniel Fagerstrom wrote:

> 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.

This can be enforced through Maven if you use the release plugin : it
will refuse to do the release if your pom has SNAPSHOT dependencies.

> 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.

You can use version ranges in Maven to tell it to retrieve the highest
version available.


> 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".

+1

> 
> Branches
> ========
> 
> 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.


+1 !


Jorg

[prev in list] [next in list] [prev in thread] [next in thread]