If you're interested in an outside perspective, it doesn't matter. It'll define itself over time, as you show discipline in providing a consistent level of quality for said name.
"Experimental" is perfectly fine. "Incubating" has certain connotations from the Apache project, so I'd actually say to stay away from it. "Unstable" is like Szczepan says, it sounds too much like "buggy". -justin On Thu, Aug 30, 2012 at 1:33 PM, Szczepan Faber < [email protected]> wrote: > -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 >
