On 30/08/2012, at 9:28 AM, Hans Dockter <[email protected]> wrote:
>
>
> 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?
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".
>
>
>
