On 13/01/10 3:37 AM, Tim Taylor wrote:
On Jan 11, 2010, at 10:04 PM, Adam Murdoch wrote:
There's some material on this stuff in the user guide in trunk. I
would link to it, but the nightly build broke last night, so the
latest user guide isn't up available at the moment.
In the vein of "teaching a man to fish", is there a moderately high
level (higher than browsing the commit log) way to find out what
features have been implemented in trunk?
Currently, there's the release notes:
http://docs.codehaus.org/display/GRADLE/Gradle+0.9+Release+Notes
and also the 'breaking changes' page:
http://docs.codehaus.org/display/GRADLE/Gradle+0.9+Breaking+Changes
One thing we don't do on the release notes, but probably should, is to
include or link to some examples.
Similarly is there a 0.9 and 0.10 roadmap that's kept current?
The roadmap is at: http://docs.codehaus.org/display/GRADLE/Roadmap
We're not very good at keeping the roadmap updated. We usually update it
just after doing a release, with our plan for the upcoming release, but
we almost never end up following the plan.
I saw on the Gradle wiki that the DSL for dependencies was changing,
that configurations were being removed. Early December I checked out
trunk hoping to experiment with the new dependency DSL, but found the
same DSL as 0.8 (I haven't checked trunk recently, so the feature may
have been implemented). I was left with uncertainties. Was the DSL
change still planned for 0.9, but unimplemented? Was it moved to 0.10
roadmap? Was the change discarded?
I think it's realistically been moved to 0.10. There'll be some
discussion about the changes on the dev list before we change stuff.
Generally, for a major DSL change, we would also let the user list know
too, to get feedback.
Having a well documented project for stable releases is hard. Keeping
a high-level changelog and up-to-date roadmap while a new release is
under development even harder. You have the former; I'm hoping you
have the latter, but won't disparage you if you don't :)
I think having a shorter release cycle might make this easier to do.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
