On Thu, 2010-04-08 at 07:22 +1000, Adam Murdoch wrote: > > On 4/04/10 7:52 PM, Russel Winder wrote: [ . . . ] > > There are occasions when the rapidity of change on a day to day basis is > > overwhelming. Of course this is the bleeding edge, so there is no > > expectation of stability. However, there are sometimes so many breaking > > changes between one snapshot release and the next that it is hard to > > keep up with the changes to the changes to the change to the . . . > > I'm not sure what we can do. I think a lot of the changes are to new > things, which haven't been included in a release. The problem is these > new things usually need a bit of 'soak time' before you get a feel for > what works and what doesn't work, and need some revision before the > release. The other breaking changes, to things which have been included > in a release, will ideally start to drop off as we get closer to a 1.0 > release. Certainly after 1.0, we'll put more effort into backward > compatibility.
Backward compatibility isn't really the issue for me, the problem is keeping track of the unobserved breaking and non-breaking changes between intermediate snapshot releases -- i.e. the version of the Gradle Wrapper used to build Gradle. GPars and Gant currently track the same Gradle Wrapper that Gradle uses. When there is a breaking change that leads to a build failure there is no problem. A question on the mailing list rapidly leads to answers, which leads to change, which leads to happiness. The problem is the hidden change -- be it breaking or otherwise. It slips by unnoticed and if there is a build up of these, all the Gradle script idioms have changed and the Gant and GPars builds look antiquated. I don't have an answer other than one that possibly imposes too much work on Hans and yourself, but let me put it forward. There is a small group of projects, Gant and GPars among them, which are trying to stay as close to the latest Gradle release as is feasible. If you were to include reviewing these and raising issues when you see them as part of a new Gradle Wrapper release with Gradle, then the above issue would be ameliorated. More importantly though, these builds would be up-to-date paradigms of Gradle use that could be pointed to in the Gradle documentation. Currently the single biggest problem with the Gradle documentation is the lack of real-world paradigms for people to look at and use to guide their use of Gradle. Having pointers to various real world Gradle builds with notes about them would be a great addition to the information pool about Gradle. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
