You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by "Daniel.Sun" <su...@apache.org> on 2018/10/13 15:40:56 UTC

Re: @Immutable backwards compatibility

Hi  Cédric,

> However, we discovered several regressions (in @CompileStatic, in
> covariant return type checking, ...) that may make the migration painful. 
      According to the changed files shown in the PR (
https://github.com/gradle/gradle/pull/6903/files ), it seems that the
migration is not that painful ;-)

      BTW, all changes for 2.5.x pass all existing tests in Groovy project.
If you find some breaking change, feel free to submit JIRA ticket to track.

Cheers,
Daniel.Sun




-----
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Re: @Immutable backwards compatibility

Posted by "Daniel.Sun" <su...@apache.org>.
Hi  Cédric,

     Paul told me what had happened. We should try our best to keep binary
compatibility between minor versions.

Cheers,
Daniel.Sun




-----
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Re: @Immutable backwards compatibility

Posted by Cédric Champeau <ce...@gmail.com>.
The "migration" may not be painful but breaking user builds or plugins when
they upgrade Gradle is not cool. Several issues have been filed already as
I understand.

Le sam. 13 oct. 2018 à 17:41, Daniel.Sun <su...@apache.org> a écrit :

> Hi  Cédric,
>
> > However, we discovered several regressions (in @CompileStatic, in
> > covariant return type checking, ...) that may make the migration
> painful.
>       According to the changed files shown in the PR (
> https://github.com/gradle/gradle/pull/6903/files ), it seems that the
> migration is not that painful ;-)
>
>       BTW, all changes for 2.5.x pass all existing tests in Groovy project.
> If you find some breaking change, feel free to submit JIRA ticket to track.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -----
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: @Immutable backwards compatibility

Posted by "Daniel.Sun" <su...@apache.org>.
Gotcha :-)




-----
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Re: @Immutable backwards compatibility

Posted by Paul King <pa...@asert.com.au>.
On Sun, Oct 14, 2018 at 1:41 AM Daniel.Sun <su...@apache.org> wrote:

> Hi  Cédric,
>
> > However, we discovered several regressions (in @CompileStatic, in
> > covariant return type checking, ...) that may make the migration
> painful.
>       According to the changed files shown in the PR (
> https://github.com/gradle/gradle/pull/6903/files ), it seems that the
> migration is not that painful ;-)
>
>       BTW, all changes for 2.5.x pass all existing tests in Groovy project.
> If you find some breaking change, feel free to submit JIRA ticket to track.
>

The problem is that none of our tests in 2.5.x include tests against 2.4.x
compiled code.
This is what impacts Gradle, Grails and Micronaut plugins. They might be
compiled
with 2.4.x and then used with 2.5.x. The checkBinaryCompatibility task
helps somewhat
but we could no doubt also add some cross version integration tests as well.


>
> Cheers,
> Daniel.Sun
>
>
>
>
> -----
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>