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!
Just update the Javadoc to say what you want to say. If it isn't
completely stable yet just try to make sure it doesn't stay that way for
too long.
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.
"Internal" to me means that no application should ever use it and that
it might be removed at a future time. What you have described is more
along the lines of "under development" or "in testing". i.e. use at
your own risk.
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
Ralph
