Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Subject: RE: on better release and version management
From: Bruno Dumon <bruno@outerthought.org>
To: dev@cocoon.apache.org
In-Reply-To: <001501c3785e$e2163130$1e01a8c0@WRPO>
References: <001501c3785e$e2163130$1e01a8c0@WRPO>
Content-Type: text/plain
Organization: Outerthought
Message-Id: <1063297755.1380.254.camel@yum.ot>
Mime-Version: 1.0
Date: Thu, 11 Sep 2003 18:29:16 +0200
Content-Transfer-Encoding: 7bit

On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote:
> From: Bruno Dumon [mailto:bruno@outerthought.org] 
> 
>  <snip/>
> 
> > I expect Woody to also take another year or so before it can 
> > be considered stable (in terms of interfaces, not code).
> 
> ... that long? I expected it to be stable sooner (end of this year).
> What's open? (I already added this discussion point to
> http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon)
> 

for one thing, there's all the stuff Sylvain's been proposing
(namespaces mixing, expression language switch, various other things,
I'll try to make a list before the hackaton).

<snip/>

> > Anyhow, lots of stuff to think about, though it'd be nice if 
> > we get some interim solution in the meantime so that we can 
> > get started on 2.2.
> 
> Yep, this interims solution is necessary and after reading Geoff's and
> Steven's posts I changed my opinion because you are right that we can't
> force block developer's to be backward compatible.
> 
> So what's our plan? From my POV it looks like:
> 
>  - create a 2.2 repository as copy (incl. history) of 2.1
>    including all the blocks (so if somebody changes 2.2 core
>    in an incompatible way I see it if I monitor the changes
>    of the block I'm interested in)

yep

>  - 2.1core only receives bug-fixes (like 2.0)

I'd judge that on a case-by-case basis, i.e. if someone wants to
backport a new 2.2 core feature to 2.1, that they simply propose that on
the list and if nobody disagrees, they can go ahead.

>  - find consensus on "What's Cocoon core?"
>  - find consensus on a road map (after we know where we want
>    to go?) and having milestones and target dates
>    (I know Cocoon is an OSS project and all those features and
>     dates are never binding for anyone but we should give our
>     user's a better overview about the project and when he/she
>     can expect a new feature)
>  - block developer's decide if they want to develop on 2.1 or 2.2
>    or when they want to switch

hmm, I think that every change made to 2.1 should also be done to 2.2
(but not vice versa of course). It would be strange that 2.1 has
features that are not in 2.2.

>  - when the block implementation of 2.2 is "useable" we can think
>    about how we continue developing our real blocks (AFAIK versioning
>    is not a problem any more with real blocks)

yep.

> 
> What do you think?

I think we're almost there. Lets wait a few more days to give others a
chance to comment, and then launch a vote.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org