Ah, sorry, I misread that. I slightly prefer the branch to have that '.x' suffix, as it is slightly more explicit. But technically there will be no difference.
On Fri, Feb 1, 2019 at 2:55 AM Chamikara Jayalath <chamik...@google.com> wrote: > Sorry, what I meant was branches+tags for each minor version release and > adding updates and tags to the same branch for patch releases. Name of the > branch can be release-2.X for minor version release 2.X.0 as Thomas > mentioned. > > - Cham > > On Thu, Jan 31, 2019 at 5:46 PM Michael Luckey <adude3...@gmail.com> > wrote: > >> Maybe we should not go so far to name branches 2.x. This will probably >> make it difficult to support more than 1 LTS. Don't know, whether we ever >> intent to do so, but supporting 2.7 and 2.13 on a 2.x branch seems >> difficult? >> >> A more explicit 2.7.x with tags 2.7.1, 2.7.2 etc might be better? If we >> are going to support a second LTS later on, we could just add that 2.??.x >> branch. >> >> michel >> >> On Fri, Feb 1, 2019 at 2:37 AM Chamikara Jayalath <chamik...@google.com> >> wrote: >> >>> +1 for 2.x branches and tags for 2.x.y releases. >>> >>> Also, I think we should integrate the dependency upgrade >>> https://issues.apache.org/jira/browse/BEAM-6552 to 2.7.1 which fixes a >>> rare but critical bug. >>> >>> Thanks, >>> Cham >>> >>> On Thu, Jan 31, 2019 at 12:17 PM Kenneth Knowles <k...@google.com> wrote: >>> >>>> It makes sense to me that 2.7 is a branch and just tags for 2.7.0, >>>> 2.7.1, etc. >>>> >>>> On Thu, Jan 31, 2019 at 11:43 AM Thomas Weise <t...@apache.org> wrote: >>>> >>>>> How about naming the branches release-X.Y and use them as base for all >>>>> the X.Y.Z releases? We already have the X.Y.Z tags to refer to the actual >>>>> release. >>>>> >>>>> On Thu, Jan 31, 2019 at 11:23 AM Charles Chen <c...@google.com> wrote: >>>>> >>>>>> 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 >>>>>>>> > > >>>>>>>> > >>>>>>>> >>>>>>>
