Hi Stefano, It is a bit unfortunate for you that you have to spend additional time to port your code to a different branch. A PR is the way to go if a commit can't be simply cherry-picked.
If your changes are too major then it is probably good idea just to include them in the next major release. Minor releases typically don't include new features. Now it's questionable whether this is a fix or a new feature :) Cheers, Max On Wed, Apr 27, 2016 at 3:18 PM, Stefano Baghino <stefano.bagh...@radicalbit.io> wrote: > Ok, thanks for the feedback. > > On Wed, Apr 27, 2016 at 3:16 PM, Till Rohrmann <trohrm...@apache.org> wrote: > >> Hi Stefano, >> >> in this case I think it's best if you opened a PR against the release >> branch so that a committer can pull it in. >> >> Cheers, >> Till >> >> On Wed, Apr 27, 2016 at 3:03 PM, Stefano Baghino < >> stefano.bagh...@radicalbit.io> wrote: >> >> > Hi Ufuk, >> > >> > thanks for getting back to me, I understand. >> > The problem with this patch in particular is that the code would be >> > slightly different between the 1.0.x and 1.1.x, so cherry-picking the >> > commit from the master branch to the release branch wouldn't be a viable >> > option, unfortunately. In this case the patch can only appear from the >> 1.1 >> > release onward? >> > >> > On Wed, Apr 27, 2016 at 2:57 PM, Aljoscha Krettek <aljos...@apache.org> >> > wrote: >> > >> > > Hi, >> > > I think what we did for now is this: When merging a PR onto the master >> > that >> > > we also consider to be required in a future release of an older release >> > > branch we cherry-pick it there and make the required changes. This only >> > > works for committers, of course, since we can just do that. >> > > >> > > I think in your case (and future cases) you can cherry-pick it on the >> > > release branch and then provide a link to your branch in the original >> PR >> > > such that the committer who merges it can also put it into the older >> > > release branch. >> > > >> > > Cheers, >> > > Aljoscha >> > > >> > > On Wed, 27 Apr 2016 at 13:38 Stefano Baghino < >> > > stefano.bagh...@radicalbit.io> >> > > wrote: >> > > >> > > > I'm currently working on FLINK-3239 >> > > > <https://issues.apache.org/jira/browse/FLINK-3239> (support Kerberos >> > on >> > > > the >> > > > Kafka connector). >> > > > >> > > > I almost have a working prototype, however now I have a doubt >> regarding >> > > how >> > > > to properly merge my code (when done): right now I'm working on a >> > branch >> > > > out of the 1.0.x release branch (apparently I could not start a >> cluster >> > > to >> > > > test on my setup because of FLINK-3824 >> > > > <https://issues.apache.org/jira/browse/FLINK-3824>). >> > > > >> > > > I'll have to make some minor change to adapt it to the master branch >> > > (it's >> > > > just a few lines of code but some of the code I had to touch have >> been >> > > > moved in the BootstrapTool.java source file); at this point I'd like >> to >> > > > make it available for both the master and the 1.0.x release branch. >> > > > >> > > > Is there any established process to handle a case like this? Is >> there a >> > > > development branch for releases? Should I perform a PR directly onto >> > the >> > > > 1.0.x branch? I would assume the latter is unadvisable, just asking >> if >> > > > that's the case. >> > > > >> > > > -- >> > > > BR, >> > > > Stefano Baghino >> > > > >> > > > Software Engineer @ Radicalbit >> > > > >> > > >> > >> > >> > >> > -- >> > BR, >> > Stefano Baghino >> > >> > Software Engineer @ Radicalbit >> > >> > > > > -- > BR, > Stefano Baghino > > Software Engineer @ Radicalbit
