cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Releases
Date Sun, 22 May 2005 19:35:01 GMT
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

Mime
View raw message