I would be in favor of keeping the old 2.7.0 release branch / tag static so that referring to it will always get the right 2.7.0 code.
On Thu, Jan 31, 2019 at 10:24 AM Kenneth Knowles <k...@apache.org> wrote: > I have waffled on whether to have release-2.7 and only branch > release-2.7.1 when starting that release. I think that whenever we release > 2.7.n the branch for 2.7.(n+1) should start from exactly that point, no? Or > perhaps on release-2.7 branch the hardcoded version strings could be > 2.7.1-SNAPSHOT/dev and remove the SNAPSHOT/dev when cutting the new release > branch? I guess I think either one is fine. I think starting the branch now > is smart, so that you can accumulate cherrypicks of backports. > > Kenn > > On Thu, Jan 31, 2019 at 7:55 AM Maximilian Michels <m...@apache.org> wrote: > >> 2.10.0 will be done when its done. Same goes for 2.7.1, which is likely >> going to >> be done later since we are focusing on 2.10.0 at the moment. >> >> I've created the release-2.7.1 branch because there is no other place for >> fixes >> of future versions. It would be helpful to have a minor version branch >> (e.g. >> release-2.7) which can be continuously updated. >> >> More generally speaking, we should dedicate time for LTS releases. What >> is the >> point otherwise of having an LTS version? >> >> -Max >> >> On 31.01.19 16:28, Thomas Weise wrote: >> > Since you were originally thinking of 2.9.x as target, 2.10.0 seems >> closer both >> > in time and upgrade path. >> > >> > I see no reason why a 2.7.1 release would materialize any sooner than >> 2.10.0. >> > >> > Or is the intention is to just stack up fixes in the 2.7.x branch for a >> > potential future release? >> > >> > Thomas >> > >> > >> > On Thu, Jan 31, 2019 at 5:03 AM Maximilian Michels <m...@apache.org >> > <mailto:m...@apache.org>> wrote: >> > >> > I agree it's better to take some extra time to ensure the quality >> of 2.10.0. >> > >> > I've created a 2.7.1 branch and cherry-picked the relevant >> commits[1]. We could >> > start collecting other fixes in case there are any. >> > >> > -Max >> > >> > [1] https://github.com/apache/beam/pull/7687 >> > >> > On 30.01.19 20:57, Kenneth Knowles wrote: >> > > Sounds good to me to target 2.7.1 and 2.10.0. I will have to >> re-roll RC2 >> > after >> > > confirming fixes for the latest blockers that were found. These >> are not >> > > regressions from 2.9.0. But they seem severe enough that they >> are worth >> > taking >> > > an extra day or two, because 2.9.0 had enough problems that I >> would like >> > to make >> > > 2.10.0 a more attractive upgrade target for users still on very >> old versions. >> > > >> > > Kenn >> > > >> > > On Wed, Jan 30, 2019 at 5:22 AM Maximilian Michels < >> m...@apache.org >> > <mailto:m...@apache.org> >> > > <mailto:m...@apache.org <mailto:m...@apache.org>>> wrote: >> > > >> > > Hi everyone, >> > > >> > > I know we are in the midst of releasing 2.10.0, but with the >> release >> > process >> > > taking its time I consider creating a patch release for this >> issue in the >> > > FlinkRunner: https://jira.apache.org/jira/browse/BEAM-5386 >> > > >> > > Initially I thought it would be good to do a 2.9.1 release, >> but since we >> > > have an >> > > LTS version, we should probably do a 2.7.1 (LTS) release >> instead. >> > > >> > > What do you think? I could only find one Fix Version 2.7.1 >> issue in JIRA: >> > > >> > >> https://jira.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20fixVersion%20%3D%202.7.1 >> > > >> > > Best, >> > > Max >> > > >> > >> >
