# Backwards compatibility issue with Gradle 1.7

**URL:** <https://discuss.gradle.org/t/backwards-compatibility-issue-with-gradle-1-7/5602>\
**Category:** Old Forum Archive\
**Created:** [August 8, 2013, 11:05am UTC](https://discuss.gradle.org/t/backwards-compatibility-issue-with-gradle-1-7/5602 "2013-08-08T11:05:00Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sean\_Reilly](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/sean_reilly/32/507_2.png) [@Sean\_Reilly](https://discuss.gradle.org/u/Sean_Reilly)\
**Post date:** [August 8, 2013, 11:05am UTC](https://discuss.gradle.org/t/backwards-compatibility-issue-with-gradle-1-7/5602/1 "2013-08-08T11:05:00Z")

</div>

I’m attempting to upgrade from gradle 1.6 to gradle 1.7, and I think I’ve encountered a potential backwards compatibility issue.

I’m using the RPM plugin as follows:

```gradle
buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.trigonic:gradle-rpm-plugin:1.3'
    }
}
   apply plugin: 'war'
 apply plugin: 'rpm'
  task rpm(type: Rpm, dependsOn: war) {
    packageName = "blah-${project.name}"
    version = "1.0.1"
    release = revision
    arch = NOARCH
    os = LINUX
   //more configuration, etc
}

```

Under gradle 1.6, this works fine, but if I run the same script with gradle 1.7, the build fails.

Stacktrace available here: [https://gist.github.com/seanjreilly/6183722](https://gist.github.com/seanjreilly/6183722)

At first glance it looks like a method has been removed from a gradle api class.

Cheers,

Sean

---

<div class="post-metadata">

**Author:** ![Peter\_Niederwieser](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@Peter\_Niederwieser](https://discuss.gradle.org/u/Peter_Niederwieser)\
**Post date:** [August 8, 2013, 3:32pm UTC](https://discuss.gradle.org/t/backwards-compatibility-issue-with-gradle-1-7/5602/2 "2013-08-08T15:32:00Z")

</div>

Already extensively discussed on dev list.

---

<div class="post-metadata">

**Author:** ![Sean\_Reilly](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/sean_reilly/32/507_2.png) [@Sean\_Reilly](https://discuss.gradle.org/u/Sean_Reilly)\
**Post date:** [August 8, 2013, 3:42pm UTC](https://discuss.gradle.org/t/backwards-compatibility-issue-with-gradle-1-7/5602/3 "2013-08-08T15:42:00Z")

</div>

Yeah, that was me. I wasn’t sure which was the better place to discuss it, so I posted it twice.

Sorry about that.

---

<div class="post-metadata">

**Author:** ![Spencer\_Allain](https://avatars.discourse-cdn.com/v4/letter/s/7ba0ec/32.png) [@Spencer\_Allain](https://discuss.gradle.org/u/Spencer_Allain)\
**Post date:** [August 11, 2013, 11:38am UTC](https://discuss.gradle.org/t/backwards-compatibility-issue-with-gradle-1-7/5602/4 "2013-08-11T11:38:00Z")

</div>

I wouldn’t consider this a double-post, as most gradle users do not monitor the dev mailing list.

I do not know how many people utilize the rpm plugin, but for those that do, this at least gives them a public heads-up that they should expect an issue.

Core gradle is a great thing, but it is very similar to Jenkins, in that many users depend upon additional plugins to cover their entire workflow.

Maybe something could be added to the release notes in the known issues section that mentions that third-party plugins that rely upon internal copy classes likely will break because of the extensive refactoring done during this release, and the rpm plugin is known to have broken?

Once the plugin portal gets into place, ideally it would provide the ability to automatically run a smoke test of simply applying each plugin against new/maintained versions of gradle, and potentially take an uploaded set of tests associated with a plugin to check compatibility (possibly with the plugin describing expected ranges of compatibility).

-Spencer