I think it is fine to fix it in branches. I do not see too much value in fixing it except in branches you know you are going to use.
The "Downloads" page is for users and only mentioned the voted source releases, maven central, and pypi. There is nothing to do with GitHub or ongoing branches there. I don't think un-published cherrypicks to branches matter to users. Did you mean some other place? Kenn On Mon, Jul 20, 2020 at 9:44 AM Alexey Romanenko <aromanenko....@gmail.com> wrote: > Then, would it be ok to fix it in branches (the question is how many > branches we should fix?) with additional commit and mention that on > “Downloads" page? > > On 8 Jul 2020, at 21:24, Kenneth Knowles <k...@apache.org> wrote: > > > > On Wed, Jul 8, 2020 at 12:07 PM Kyle Weaver <kcwea...@google.com> wrote: > >> > To fix on previous release branches, we would need to make a new >> release, is it not? Since hashes would change.. >> >> Would it be alright to patch the release branches on Github and leave the >> released source as-is? Github release branches themselves aren't release >> artifacts, so I think it should be okay to patch them without making a new >> release. >> > > Yea. There are tags for the exact hashes that RCs were built from. The > release branch is fine to get new commits, and then if anyone wants to > build a patch release they will get those commits. > > Kenn > > >> On Wed, Jul 8, 2020 at 11:59 AM Pablo Estrada <pabl...@google.com> wrote: >> >>> Ah that's annoying that a dependency would be removed from maven. I >>> thought that was not meant to happen? This must be an issue happening for >>> many other projects... >>> Why is errorprone a dependency anyway? >>> >>> To fix on previous release branches, we would need to make a new >>> release, is it not? Since hashes would change.. >>> >>> On Wed, Jul 8, 2020 at 10:21 AM Alexey Romanenko < >>> aromanenko....@gmail.com> wrote: >>> >>>> Hi Max, >>>> >>>> I’m +1 for back porting as well but that seems quite complicated since >>>> we distribute release source code from https://archive.apache.org/ >>>> Perhaps, we should just warn users about this issue and how to >>>> workaround it. >>>> >>>> Any other ideas? >>>> >>>> > On 8 Jul 2020, at 11:46, Maximilian Michels <m...@apache.org> wrote: >>>> > >>>> > Hi Alexey, >>>> > >>>> > I also came across this issue when building a custom Beam version. I >>>> applied the same fix (https://github.com/apache/beam/pull/11527) which >>>> you have mentioned. >>>> > >>>> > It appears that the Maven dependencies changed or are no longer >>>> available which causes the missing class files. >>>> > >>>> > +1 for backporting the fix to the release branches. >>>> > >>>> > Cheers, >>>> > Max >>>> > >>>> > On 08.07.20 11:36, Alexey Romanenko wrote: >>>> >> Hello, >>>> >> Some days ago I noticed that I can’t build the project from old >>>> release branches . For example, I wanted to build and run Spark Job Server >>>> from “release-2.20.0” branch and it failed: >>>> >> ./gradlew :runners:spark:job-server:runShadow —stacktrace >>>> >> * Exception is: >>>> >> org.gradle.api.tasks.TaskExecutionException: Execution failed for >>>> task ':model:pipeline:compileJava’. >>>> >> … >>>> >> Caused by: org.gradle.internal.UncheckedException: >>>> java.lang.ClassNotFoundException: >>>> com.google.errorprone.ErrorProneCompiler$Builder >>>> >> … >>>> >> I experienced the same issue for “release-2.19.0” and >>>> “release-2.21.0” branches, I didn’t check older branches but seems it’s a >>>> global issue for “net.ltgt.gradle:gradle-errorprone-plugin:0.0.13". >>>> >> This is already known issue and it was fixed for 2.22.0 [1] a while >>>> ago. By applying a fix from [2] on top of previous branch, for example, >>>> “release-2.20.0” branch I’ve managed to build it. Though, the problem for >>>> old branches (<2.22.0) is still there - it’s not possible to build them >>>> right after checkout without applying the fix. >>>> >> So, there are two questions: >>>> >> 1. Is anyone aware why the old static version of >>>> gradle-errorprone-plugin fails for the branches that were successfully >>>> built before? >>>> >> 2. Do we have to fix it for release branches <2.22.0 (either >>>> cherry-pick the fix for 2.22.0 or somehow else if it’s possible)? >>>> >> [1] https://issues.apache.org/jira/browse/BEAM-10263 >>>> >> [2] https://github.com/apache/beam/pull/11527 >>>> >>>> >
