cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Releasing 2.1.8, when?
Date Thu, 01 Sep 2005 09:56:21 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>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.
>Yepp, that's all true and we agreed several times to mark the api, but
>unfortunately it never happened :(
>With your location stuff, I think the api changes effect only java
>developers, so I think we can even release the current state and change
>things there later on.

Hmm... Java APIs are our contracts also...

>Now, if we have a fixed schedule (every two months), people know that
>they have to "finish" new work before the next release and they know
>when this release will be. This does not solve the problem you describe,
>but it might lessen it a little bit.

That's right. And at the very end, some unfinished features (API-wise) 
can be temporarily removed to make the release and re-added afterwards.

>Ok, so, what about just marking those new editions with TODO or NOT
>FINISHED or whatever?

"editions"? Do you mean the new features? Yes, that's the idea: put on 
them a special flag so that people know that these are used internally 
but that they should not have their code depend on them.


Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message