On Thu, Aug 30, 2012 at 10:18 AM, Luke Daley <[email protected]> wrote:
> > > > > On 30/08/2012, at 8:27 AM, Hans Dockter <[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? > 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. 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. So I like incubation quite a bit. Hans > > I want to stay well away from "experimental". >
