cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Releasing 2.1.8, when?
Date Thu, 01 Sep 2005 09:15:31 GMT
Daniel Fagerstrom wrote:

> Carsten Ziegeler wrote:
>
>> My original idea was to release 2.1.8 after the GT, so announcing the
>> code freeze the week after the GT and releasing one week later. In the
>> last years, we had the famous bug hunt at the GT and fixed/improved
>> several things. This year we have two days for the hackathon so we
>> should be able to do even more.
>>
>> But we can release sooner if required; I think the current state is very
>> stable.
>>
>> I think from 2.1.8 we should simply release every two months. So
>> everyone (developers and users) have a fixed date. So this is a little
>> bit more of agile development as we are using fixed sprints :)
>> Of course if there are showstoppers we will make an exception.
>

Although I agree with the general principle of shorter release cycles, 
we have to define a policy regarding new features introduced in these 
frequent releases and the associated contracts. Again, stable / unstable 
state, but at a finer intra-block level.

Let's take an example with the new Location stuff. It's very cool and a 
lot of people will want to use it. However, we may not consider the API 
totally finished (there are still a few minor changes I'd like to do for 
it to be cleaner and more straightforward). What if we make a release 
now? The contracts will have changed a bit in the next release!

So this leads back to a discussion we already had: marking some APIs as 
internal, so that people are warned that they should not base their code 
on it. The internal status can be used for things that are really 
internal (like all the environment handling stuff) and things that are 
fully functionnal (i.e. "stable" from a bug point of view) but on which 
we still reserve the right to do some modifications.

Another solution of course would be to use branches, but this isn't very 
practical for fine-grained things like outlined above.

Just some thoughts...

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message