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
