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