Ralph Goers wrote:
Daniel Fagerstrom wrote:
<snip/>
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.
Most definitively not. It should be rather clear from my activities on
the list that I find community discussions and votes being of
fundamental importance.
What I oppose is the current practice to say that the features so and so
are required before we can relase version X.Y and then letting it stall
for ever because this set of "nice to have" wasn't important enough for
anyone to actually implement it.
OTH people, hopefully after community discussions, introduce new usefull
stuff all the time. We should IMO be more realistic and base our relases
and numbering on what actually become implemented.
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".
Exactly. Planning and even wishfull thinking are good things. But we
shouldn't let our release schedule be to dependent on wishfull thinking ;)
--- 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.
IMO we should be able to create a stable delivery from trunk at all
times. Cocoon contains a lot of stuff, some of it is in heavy use and
have been part of Cocoon for a long time. When refactoring and adding
features to these parts utermost care and testing is IMO always a
requirement. OTH there are many things, also in 2.1.x that is in early
stages of develpment, isn't tested or have few or no users.
I doubt that it is meanifull to talk about something as large as Cocoon
as "stable" or "unstable" as it by its nature must have parts in
different stages of stabilty at all times. This is one reason that I
find it so important to split Cocoon in blocks (or bundles). Then we get
small enough unities to be able to talk about stability at bundle level.
When we have branched Cocoon it has always been motivated with the need
to experiment and being allowed to let core stuff be unstable for an
extended period. But in retrorespect I wonder if this rally have given
us that much. For 1.0->2.0, sure but after that?
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.
The plans that I have proposed are incremental. I might of course have
missed important aspects. In that case we will see that in due time and
can decide then about what to do.
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.
Exactly, and I believe that this in part depends on the idea that
radical change is needed. I have seen very few examples on when "next
generation" projects actually have succeded and numerous when they
haven't. So I'm rather suspicious about all plans that requires radical
change. To me it sounds like a recepie for dissaster and that one
haven't thought enough about how to get from here to there.
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.
Yes.
--- 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.
We all want to see Cocoon Forms marked stable. But most of us, I for
example, don't do anything to make it happen.
Second, has anybody stress
tested trunk? Or documented what incompatibilities have been
introduced? Or even what features it provides?
Don't know. Reinhard and maybe Sylvain at least seem to use it for
customer systems maybe there are more.
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....
This is the most popular reference:
http://www.anyware-tech.com/blogs/sylvain/archives/000171.html
So, convince me that trunk is ready for prime time and then I'll agree.
It's not ready for prime time but it is ready for being released as
alpha. It will need some time and testing and API tidying before we can
mark it as stable.
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.
I am ;)
/Daniel
