Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: Jorg Heymans <jh@domek.be>
Subject: Re: [M10N] new repo layout
Date: Sat, 05 Nov 2005 19:25:09 +0100
Lines: 80
Message-ID: <dkite1$kda$1@sea.gmane.org>
References: <dkd6c9$ucm$1@sea.gmane.org> <436A2490.9090302@reverycodes.com>
 <436A4A69.2070909@nada.kth.se> <436AC65F.8070508@reverycodes.com>
 <436B5AAF.9000301@nada.kth.se> <436B7B3E.2060306@reverycodes.com>
 <436CD127.5050400@nada.kth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
In-Reply-To: <436CD127.5050400@nada.kth.se>
Sender: news <news@sea.gmane.org>


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