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. 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
