On 8 May 2014 at 2:08:56 am, Steve Ebersole ([email protected]) wrote:
On the selfish side, personally I'd say that I have no compelling reason to upgrade (heck Hibernate is still using 1.9) because none of the bugs/requests I have reported have been addressed. These range from LONG standing, simple ones like standardized "provided" configuration support to more complex ones. Given that I would actually want to help (either because an RC includes fixes for one or more of my reports, or because I am a good citizen) both of your suggestions are good. Out of curiosity, why limit latest to just rc? These are just the regressions from the 1.12 release, nothing else. Regressions always have the highest priority. On Wed, May 7, 2014 at 10:50 AM, Daz DeBoer <[email protected]> wrote: G'day It appears that a few regressions slipped into the 1.12 release. Here's the list of possible regressions that I'm aware of: GRADLE-3076: Gradle 1.12-rc-2 fails with UnsatisfiedLinkError on some Linux versions This was reported in 1.12-rc-2. Was it fixed for 1.12? GRADLE-3079: Method in build.gradle not available in imported scripts (regression in 1.12) This is the classloader regression in "apply from" that Luke is working on GRADLE-3080: gradle 1.12 now downloads snapshots when I apply a version range Not sure if this has been verified, but I suspect it's due to the changes to version listing that I did GRADLE-3081: gradle 1.12 tries to resolve custom packaging with .jar extension Not sure if this has been investigated/verified, but it sounds credible GRADLE-3082: "class loader scope is locked" error when building GroovyFX with Gradle 1.12 This has been verified by Peter I guess we need to decide which of these should be fixed for 2.0, and make fixing them a priority. We should also update the "Affects Version" for any that are verified regressions. Regarding the underlying issue of regressions: the RC phase for 1.12 was over 2 weeks long, so perhaps the reason these weren't caught is that there's little pressure for people to try out the RC, particular when we release so frequently. I'm not sure there's any "solution" to this, but some things that might help are: Release more frequently (4-6 weeks), so that regressions don't cause too much pain and each release contains less stuff Make it easy for users to configure a build to always run with the latest gradle. Something like "latest.rc" in the wrapper config, or a command-line override. That way, more people might setup CI jobs that would catch regressions in the RC phase. -- Darrell (Daz) DeBoer Principal Software Engineer, Gradleware Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com — Luke Daley Gradleware Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
