Incubating is a term a lot of folks will understand due to Apache's use
of it. Not sure that is a good thing ;)
At JBoss we use the phrase "tech preview" to cover the cases you
mentioned. Another suggestion.
On Thu 30 Aug 2012 03:37:58 AM CDT, Luke Daley wrote:
On 30/08/2012, at 9:28 AM, Hans Dockter <[email protected]
<mailto:[email protected]>> wrote:
On Thu, Aug 30, 2012 at 10:18 AM, Luke Daley <[email protected]
<mailto:[email protected]>> wrote:
On 30/08/2012, at 8:27 AM, Hans Dockter
<[email protected]
<mailto:[email protected]>> wrote:
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
I strongly want to avoid more than one term as it's too confusing
for users.
I see two things we want to communicate:
1. The public API is in flux, and/or
2. The feature is incomplete in terms of stability so we expect
some issues
The reason we release stuff with these characteristics is that
putting in the hands of users early makes it better in the long
run and it may be good enough for some.
I like the term "incubating" more than "unstable". It implies
that it's growing; moving forward. A precedent for this term
would be the ASF incubation process.
The term "unstable" is too negative to me.
Although it is used a lot in the linux distribution/development world?
Yeah it is.
And that's such a user friendly/centric environment right? :) (I'm
going to get it from a Linux person for that).
While "incubating" has a positive feel.
Incubating is an appealing alternative. I agree that it is more
positive. The only argument that comes to my mind against it is that
it might not manage the expectation properly that the API is changing.
I think that's a good thing. It describes the state of the feature,
and we then can define the characteristics of a feature in that state.
Different kinds of features may have different characteristics during
incubation. While some characteristics, e.g. unstable public API,
applies to all incubating features.
Than again you can't specify everything perfectly with one word
anyhow. It is our job in the release notes and in the other
documentation to define what we exactly mean by it.
Yes, and we would use it consistently and universally which aids
understanding.
So I like incubation quite a bit.
Hans
I want to stay well away from "experimental".
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
