cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject RE: on better release and version management
Date Thu, 11 Sep 2003 11:32:14 GMT
On Thu, 2003-09-11 at 12:02, Reinhard Poetz wrote:
> > From: Bruno Dumon
> 
> > > Carsten made a good proposal how we can continue having 3 
> > repositories 
> > > and how this can be done with only little code duplicating: 
> > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=2
> > > 
> > > I'm +1 with his proposal - the reason is simple: Some people (and 
> > > customers too!) asked me if we have gone crazy and how they 
> > can update 
> > > Cocoon in the future without being alpha/beta-tester for 
> > 'real' blocks 
> > > and Fortress. We *must* be able to maintain 2.1 without all new 
> > > features like blocks and Fortress because IMNSHO these steps are to 
> > > big for 2.1 and I'm -1 on the changes in the current repository.
> > 
> > I'm also +1 for starting a new repository, but I don't like 
> > Carsten's proposal that much. I'd rather see the entire 
> > repository duplicated, and move all development effort to the 
> > 2.2 repository. Only bugfixes should be applied to the 2.1 
> > repository, and occasional backports of new functionality if 
> > anyone wants to.
> 
> 
> Let's look which new features are planned for the next time and when
> they will be ready for beta and for final release?
> 
>  - real blocks
>  - virtual sitemap components
>  - intercepted flowscript
>  - use Fortress as container
>  - Cocoon Forms (aka Woody)
>  - Cocoon Portals (new portal block)
> 
> IMO the first four items should be part of 2.2 but the two last items
> should be released earlier. Let's assume a szenario that the
> implementation of them takes very long (e.g. more than a year until we
> reach a stable version). Do you really want to wait with Cocoon Forms
> and Cocoon Portals such a long time (not to mention the many other
> blocks)?

I expect Woody to also take another year or so before it can be
considered stable (in terms of interfaces, not code).

Fortress itself is already stable, and if all goes well its impact on
Cocoon stability should be minimal.

Real blocks will take some more time, though my impression is that it's
mainly new stuff, and won't impact the stability of what we currently
have that much.

So people who want to get quick access to the latest and greatest will
be able to use snapshots or milestone releases, just as before.

But I get your point: it could be that e.g. Woody is "finished" halfway
through 2.2 development.

>  You can say now that you develop under 2.2 and you do
> occasional backports

correction: I didn't say *I* will do occasional backports :-) These will
only happen if someone's motivated to do so.

>  but IMO the problem is that e.g. Cocoon Forms is
> tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable
> branch!

You'll always have to test it on all releases that you make it available
on, that's unavoidable. If you make a Windows app, you also have to test
it on all different Windows releases.

>  Additionally we get a great mess with all our blocks if they are
> duplicated, some are backported, some not and we developers have to do a
> lot of work twice, work which is not real fun.
> 
> That's the reason why I'm +1 with Carstens proposal:
> 
>  - 2.1 repository containing all our blocks
>  - 2.2 repository contains only the new stuff introduced by the first
>        four points from above
>  - the 2.2 build mechanism is 'clever' enough to get all sources
>    from 2.1 that are missing
> 
> What do you think?

There's lots of value in that proposal, but some problems too.

I see the 2.1.x releases as patch releases, which must be releasable on
very short notice. (but maybe that's wrong in itself, and the 2.1.x.x
releases should be patch releases).

What if I want to do "heavy development" on a block that will make it
unstable for a while? If it's then suddenly required to release a patch
release, that block will be part of it in its unstable state.

Another problem: what if in my block I want to make use of features only
available in 2.2. Or what if we make backwards incompatible changes in
Cocoon 2.2 that require some changes (even if only minimal) to some
blocks (we don't have #ifdef's).

A better solution might be to move the blocks to their own repository,
give them their own release management, make each block define its own
requirements in terms of required Cocoon version etc. But that will
bring a whole lot of work with it too, and I'm not sure we really need
that.

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.

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


Mime
View raw message