So far we have used the term experimental for features with the following
attributes:

- The implementation quality of the feature was already as good as it gets.
But the API is not stable yet.
- We were not sure whether the implementation quality was production ready
(or we knew already that it wasn't). We don't release usually half baked
stuff. But for features that are tough engineering challenges like the
Gradle daemon or now the parallel build there is no chance to get it right
from the beginning.
- Both of the above.

I'm not sure if the term experimental is the right one. When I hear
experimental, my association is:
1.) That we are not sure yet whether the feature is of value to our users.
We might drop it in the future.
2.) The quality is not very high.

1.) has never been the case of any of the features we are introducing as
experimental.
2.) Might be the case, see above.

I think it is pretty important to get the terminology right here as this
'experimentalness' is a crucial part of our development process (see:
http://forums.gradle.org/gradle/topics/the_gradle_release_approach).

We don't want to make things unnecessary complex. Then again we don't want
that people get a misunderstanding.

For some of those features the term unstable is I think the best one. If I
had to decide between the term experimental or unstable I would go for
unstable. It is also an established term for linux development. Another
question is whether we want to use different terminologies to better
capture the two scenarios decribed above. My feeling is that this is not
necessary. For specific features like parallel build we can always print
tailored warnings that manage the expectations for those features.

So what I would like to discuss is whether we should use the term unstable
instead of experimental:
- When we talk about it in the forum
- In the release notes
- In the DSL

Hans

--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleware
CEO, Gradleware - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply via email to