cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [RT] Releases
Date Sun, 22 May 2005 17:32:03 GMT
Daniel Fagerstrom wrote:

> <snip>
> Since 2000 we have managed to ship a handfull of 2.0 and a handfull of 
> 2.1 releases. Considering the amount of activity and the volume and 
> quality of what have done during that period it must be a hard to beat 
> record in conservative version numbering ;)
>                   --- o0o ---
> IMO we should find a less demanding and more realistic attitude for 
> Cocoon releases, so that we can go towards "release early, release 
> often".

More frequent releases would be a good thing.

> Planning what should be part of the next major release seem harmfull, 
> as the relase can stall forever if there is a difference between what 
> we would like to have in the release and what we actually are 
> implementing.

I don't think I understand.  Or maybe I do.  It sounds like you just 
want to do stuff and release with no community discussion over the 
direction Cocoon should go. However, I agree that just discussing 
endlessly is pretty useless.  But planning is a good thing - even if it 
just means saying "no your enhancement cannot go in the next release 
because it breaks incompatibility, but it can go in the following one if 
we provide warning now".

>                   --- o0o ---
> IMO we should *only* work at trunk. No "stable" branches, we should 
> instead making sure that core functionality always is stable, and find 
> incremental ways for changing core functionality.

Absolutely disagree.  Stable branches are required so that you can 
maintain a stable delivery at all times.  2.1 is doing very well in that 
regard. I cannot see how we could move to an architecture that supports 
real blocks in an incrementatl fashion while maintaining the stability 
we need to provide our customers. 

However, from reading some of your other comments we may not be very far 
apart.  BRANCH_2_1_X was probably not the best name.  If STABLE had been 
chosen then we could be doing what you are proposing on that branch, 
while leaving trunk open for some of the more radical changes we are doing.

The real issue here is that we all know we need to get to the "real 
block" architecture, but we simply have not been able to make it happen 
for the last 2 years.

> If we, after having voted about it, introduce back incompability, it 
> means that the next release should go from 2.1.x to 2.2.0 e.g. It 
> shouldn't be a greater deal than so. We can also step up the version 
> because we feel that we want to marketing some important addition.
> We should base our releases on what we actually have done rather on 
> what we wish that someone else should develop.

There is some truth to this, but we could be doing this today.  All this 
means is that when we wish to deliver something that introduces an 
incompatibility we do it purposefully on the "stable" branch, and we 
change the release number accordingly.  As I recall this is right in 
line with the version document we agreed upon that Carsten referenced.

>                   --- o0o ---
> For our current situation I think we could release a 2.2.0 right away. 
> It doesn't contain what we planned for but OTH it contains a lot of 
> goodies that we didin't plan for and that should be usefull for a 
> larger audience.

First, I want to see Cocoon Forms marked stable, even if the next 
release is 2.1.8, IMO that has got to happen. 
Second, has anybody stress tested trunk? Or documented what 
incompatibilities have been introduced?  Or even what features it 
provides?  Heck, if someone asked me what the benefit of the current 
trunk is over the 2.1.X branch I don't think I could tell them.  I know 
the core has changed a lot....
So, convince me that trunk is ready for prime time and then I'll agree.

> When/if we finish the blocksl, or some other important stuff we can 
> release 2.3 or even 3.0 if we feel like it.
>                   --- o0o ---
> I haven't made much release related work in the past and its far from 
> my number one itch right now, so this take this semi rant for what it is.
> But IMO we should stop this wishfull thinking based "major next 
> version"  nonsense, sooner rahter than later. And also stop difussing 
> our energy in pointless branching.

In my view, the problem here is that we all want "real blocks".  Not 
delivering that is extremely disappointing and frustrating.  What is 
worse, whenever we do stuff to the core I don't think we are actually 
sure we are getting any closer to the goal.  That's why we get excited 
when we see some new thing come along that looks like it will get us a 
significant way towards the goal. 

We actually don't do a lot of branching.  In some environments a branch 
is cut for every release so that maintenance can be performed against 
previously shipped releases.  Be thankful we don't do that.

> We should be proud of what we *actually* achieve, and step up the 
> first decimal as soon as we have added some important feature.
> /Daniel

View raw message