cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <>
Subject RE: on better release and version management
Date Thu, 11 Sep 2003 12:19:00 GMT

From: Bruno Dumon [] 


> 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

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

I think so too.

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

Yep, got your point.

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

Ok. We are back at the beginning of the discussion. I think all those
points made Stefano to publish his blocks proposal. Only 'real' blocks
will decouple block development from Cocoon development and that's the
major point (at least for me) making worth all the efforts of discussion
and implementation.

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

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)
 - 2.1core only receives bug-fixes (like 2.0)
 - 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
 - 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)

What do you think?


View raw message