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: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

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