cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Releasing 2.1.8, when?
Date Thu, 01 Sep 2005 09:43:15 GMT
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.
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.
Ok, so, what about just marking those new editions with TODO or NOT
FINISHED or whatever?


Carsten Ziegeler - Open Source Group, S&N AG

View raw message