Hi Justin, On Thu, Aug 30, 2012 at 11:19 PM, Justin Ryan <[email protected]> wrote:
> 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. This is definitely the most important aspect about it. > > "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". > What I like with Incubating is its organic connotation. Something is growing, needs further input, is getting refined. All that is exactly what we are doing with those kind of features. Experimental is too much about that we don't know whether it is of some value at all and we might kick it out later on. I'm not sure about the Apache connotation. I mean this would be an incubator in a very different ecosystem. So honestly I'm not too much concerned about this. What Apache was trying to establish with that is nonetheless something similar to what we want to do. And as you said above, the most important thing providing a consistent level of quality and not having too many things incubating but rather turn them into production quality before incubating the next thing. So my vote goes for incubating. I also like Preview or TechPreview but Incubating hits even better what we are trying to do. 1.2 will be the first release that has quite a few of incubating features. Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com > > -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 >> > >
