Ralph Goers 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!
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.
That's the point: periodic releases may clash with ongoing development,
meaning an interim state for one release. Now as Daniel rightly pointed
out, having fixed dates will likely change our developer habits.
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.
Right, but making it "internal" is stronger as it means "don't use it",
as internals can change also without notice.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
