-1 for 'experimental'
+5 for 'incubating'
-5 for 'unstable' (unstable == buggy in my mind)

I don't mind separating concerns / having more than 1 term.

Cheers!

On Thu, Aug 30, 2012 at 2:58 PM, Steve Ebersole
<[email protected]>wrote:

> 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:hans.dockter@**gradleware.com <[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:hans.dockter@**gradleware.com <[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<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<http://xircles.codehaus.org/manage_email>
>
>
>


-- 
Szczepan Faber
Principal engineer@gradleware
Lead@mockito

Reply via email to