On Thu, Aug 30, 2012 at 11:00 PM, Adam Murdoch <[email protected]>wrote:
> > I'm opting out of this discussion. I'm fine with 'experimental', > 'unstable' or 'incubating' or 'tech preview' or whatever. You need to make > a decision quickly, because we'll need to change all references to > 'experimental' in the code and documentation before we can get 1.2-rc-1 out. > > A better time to have this discussion would have been when I sent the spec > around, rather than the day we're trying to get a release out. That's the > point of the specs - to document what we're going to do before we do it, so > that people can give feedback. > We had a couple of times the discussion around the terminology and that at least was wondering about something better. I should have turned it into a story tough. Hans > > > On 30/08/2012, at 5:27 PM, Hans Dockter 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 > > Hans > > -- > Hans Dockter > Founder, Gradle > http://www.gradle.org, http://twitter.com/gradleware > CEO, Gradleware - Gradle Training, Support, Consulting > http://www.gradleware.com > > > > > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
