You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Maximilian Michels <mx...@apache.org> on 2019/01/30 13:22:35 UTC
2.7.1 (LTS) release?
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
Re: 2.7.1 (LTS) release?
Posted by Kenneth Knowles <ke...@apache.org>.
By that last bit of logic, wouldn't it also work for master to public
2-SNAPSHOT? It feels a bit odd, though I don't have a concrete objection. I
expect it is easier for tools and our own scripts if we stick to 3 part
versions even when we don't have to.
Kenn
On Thu, Jan 31, 2019 at 6:18 PM Thomas Weise <th...@apache.org> wrote:
> Hi,
>
> As Kenn had already examplified, the suggestion was to have branches:
>
> 2.7
> 2.8
> 2.9
> ...
>
> and tags:
>
> 2.7.0
> 2.7.1
> ...
> 2.8.0
> ...
>
> Changes would go to the 2.7 branch, at some point release 2.7.1 is
> created. Then more changes may accrue on the same branch, maybe at some
> point 2.7.2 is released and so on.
>
> We could also consider changing the snapshot version to 2.7-SNAPSHOT,
> instead of 2.7.{0,1,...}-SNAPSHOT.
>
> With that it wouldn't even be necessary to change the version number on
> the branch.
>
> Thanks,
> Thomas
>
>
>
> On Thu, Jan 31, 2019 at 5:59 PM Michael Luckey <ad...@gmail.com>
> wrote:
>
>> 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 <ch...@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 <ad...@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 <ch...@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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <mx...@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 <
>>>>>>>>>> mxm@apache.org
>>>>>>>>>> > <ma...@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 <
>>>>>>>>>> mxm@apache.org
>>>>>>>>>> > <ma...@apache.org>
>>>>>>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>>>>>>> > >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
Re: 2.7.1 (LTS) release?
Posted by Kenneth Knowles <kl...@google.com>.
Robert: exactly
Max: no reverting, because of what Robert said. They just have a parent
pointer onto the branch. I will update the bash script(s).
Kenn
On Fri, Feb 8, 2019 at 7:36 AM Robert Bradshaw <ro...@google.com> wrote:
> +1, I've always found it odd that our build process creates and then
> reverts commits in the branch (and had the same issue when I was doing the
> release that restarting if something went wrong was painful). If I
> understand correctly, a, b, and c would be tags in the github repository,
> but not live on any particular branch? I think this is much nicer.
>
> On Fri, Feb 8, 2019 at 4:03 PM Maximilian Michels <mx...@apache.org> wrote:
>
>> Looks like a good improvement.
>>
>> It makes sense to have the snapshot version on the release branch and
>> only change it to a proper version before creating the RC.
>>
>> Do we still revert a, b, c after creating the RC? Otherwise the bash
>> script which replaces "-SNAPSHOT" won't work correctly.
>>
>> -Max
>>
>> On 06.02.19 20:21, Kenneth Knowles wrote:
>> > Having gone through the release process, I have a couple of git
>> drawings
>> > to share. Currently the release process looks like this (you'll have to
>> > view in fixed width font if it is stripped by the mail manager).
>> >
>> > -----X---------------------------- master
>> > \
>> > ---Y-----a------b-------c----- release-2.10.0
>> >
>> > * X: commit that updates master from 2.10.0-SNAPSHOT to
>> > 2.11.0-SNAPSHOT (Python calls it 2.10.0dev, etc per lang, and we wrote
>> a
>> > script for it)
>> > * The release branch starts the release branch from parent of X
>> > * Y: changes Python version to 2.10.0 (no dev) and you'll see why
>> > * On release branch, version is still 2.10.0-SNAPSHOT for Java
>> > * a, b, c: the gradle release plugin commits a change for Java to
>> > 2.10.0 then reverts it, and tags with RC1, RC2, RC3, etc. If the RC
>> > fails you have to force reset and delete the tag.
>> > * The release script also builds from fresh clones, so this is all
>> > pushed to GitHub. It can really clutter the history but is otherwise
>> > probably harmless. Because of issues with scripting and gpg set up I
>> had
>> > to build maybe 10 "RCs" to roll RC2.
>> >
>> > I think git can make this simpler. I would propose:
>> >
>> > -----X---------------------------- master
>> > \
>> > ----------------------- release-2.10.0
>> > \ \ \
>> > a b c
>> > * X: same
>> > * Y: gone
>> > * On release branch, both Java and Python are -SNAPSHOT or dev, etc.
>> > (and it could be release-2.10 that advances minor version in the commit
>> > after a succesful RC)
>> > * To build an RC, add the commits like a, b, c which remove
>> -SNAPSHOT
>> > and tag; we have a bash script that collects all the places that need
>> > editing, the one that built commit X.
>> > * Whether to push the commit and tag first or build the RC first
>> > doesn't matter that much but anyhow now it is off the history so it is
>> > fine to push.
>> >
>> > Have I missed something vital about the current process?
>> >
>> > Kenn
>> >
>> >
>> >
>> > On Thu, Jan 31, 2019 at 8:49 PM Thomas Weise <thw@apache.org
>> > <ma...@apache.org>> wrote:
>> >
>> > Either looks fine to me. Same content, different label :)
>> >
>> >
>> > On Thu, Jan 31, 2019 at 6:32 PM Michael Luckey <adude3141@gmail.com
>> > <ma...@gmail.com>> wrote:
>> >
>> > Thx Thomas for that clarification. I tried to express, I d
>> > slightly prefer to have branches
>> >
>> > 2.7.x
>> > 2.8.x
>> > 2.9.x
>> >
>> > and tags:
>> > 2.7.0
>> > 2.7.1
>> > ...
>> >
>> > So only difference would be to be more explicit on the branch
>> > name, i.e. that it embraces all the patch versions. (I do not
>> > know how to better express, that '2.7.x' is a literal string and
>> > should not be confused as some placeholder.)
>> >
>> > Regarding the versioning, I always prefer the explicit version
>> > including patch version. It might make it easier to help and
>> > resolve issues if it is known on which patch level a user is
>> > running. I spent lot of lifetime assuming some version and
>> > realising later it was 'just another snapshot' version...
>> >
>> > Just my 2 ct... Also fine with the previous suggestion.
>> >
>> >
>> >
>> > On Fri, Feb 1, 2019 at 3:18 AM Thomas Weise <thw@apache.org
>> > <ma...@apache.org>> wrote:
>> >
>> > Hi,
>> >
>> > As Kenn had already examplified, the suggestion was to have
>> > branches:
>> >
>> > 2.7
>> > 2.8
>> > 2.9
>> > ...
>> >
>> > and tags:
>> >
>> > 2.7.0
>> > 2.7.1
>> > ...
>> > 2.8.0
>> > ...
>> >
>> > Changes would go to the 2.7 branch, at some point release
>> > 2.7.1 is created. Then more changes may accrue on the same
>> > branch, maybe at some point 2.7.2 is released and so on.
>> >
>> > We could also consider changing the snapshot version to
>> > 2.7-SNAPSHOT, instead of 2.7.{0,1,...}-SNAPSHOT.
>> >
>> > With that it wouldn't even be necessary to change the
>> > version number on the branch.
>> >
>> > Thanks,
>> > Thomas
>> >
>> >
>> >
>> > On Thu, Jan 31, 2019 at 5:59 PM Michael Luckey
>> > <adude3141@gmail.com <ma...@gmail.com>> wrote:
>> >
>> > 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
>> > <chamikara@google.com <ma...@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
>> > <adude3141@gmail.com <ma...@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 <chamikara@google.com
>> > <ma...@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 <klk@google.com
>> > <ma...@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 <thw@apache.org
>> > <ma...@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 <ccy@google.com
>> > <ma...@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 <
>> kenn@apache.org
>> > <ma...@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
>> > <mxm@apache.org
>> > <ma...@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 <mxm@apache.org
>> > <ma...@apache.org>
>> > >
>> > <mailto:mxm@apache.org
>> > <ma...@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
>> > <mxm@apache.org
>> > <ma...@apache.org>
>> > >
>> > <mailto:
>> mxm@apache.org
>> > <mailto:mxm@apache.org
>> >>
>> > > >
>> > <mailto:mxm@apache.org
>> > <ma...@apache.org>
>> > <mailto:mxm@apache.org
>> > <mailto:mxm@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
>> > > >
>> > >
>> >
>>
>
Re: 2.7.1 (LTS) release?
Posted by Robert Bradshaw <ro...@google.com>.
+1, I've always found it odd that our build process creates and then
reverts commits in the branch (and had the same issue when I was doing the
release that restarting if something went wrong was painful). If I
understand correctly, a, b, and c would be tags in the github repository,
but not live on any particular branch? I think this is much nicer.
On Fri, Feb 8, 2019 at 4:03 PM Maximilian Michels <mx...@apache.org> wrote:
> Looks like a good improvement.
>
> It makes sense to have the snapshot version on the release branch and
> only change it to a proper version before creating the RC.
>
> Do we still revert a, b, c after creating the RC? Otherwise the bash
> script which replaces "-SNAPSHOT" won't work correctly.
>
> -Max
>
> On 06.02.19 20:21, Kenneth Knowles wrote:
> > Having gone through the release process, I have a couple of git drawings
> > to share. Currently the release process looks like this (you'll have to
> > view in fixed width font if it is stripped by the mail manager).
> >
> > -----X---------------------------- master
> > \
> > ---Y-----a------b-------c----- release-2.10.0
> >
> > * X: commit that updates master from 2.10.0-SNAPSHOT to
> > 2.11.0-SNAPSHOT (Python calls it 2.10.0dev, etc per lang, and we wrote a
> > script for it)
> > * The release branch starts the release branch from parent of X
> > * Y: changes Python version to 2.10.0 (no dev) and you'll see why
> > * On release branch, version is still 2.10.0-SNAPSHOT for Java
> > * a, b, c: the gradle release plugin commits a change for Java to
> > 2.10.0 then reverts it, and tags with RC1, RC2, RC3, etc. If the RC
> > fails you have to force reset and delete the tag.
> > * The release script also builds from fresh clones, so this is all
> > pushed to GitHub. It can really clutter the history but is otherwise
> > probably harmless. Because of issues with scripting and gpg set up I had
> > to build maybe 10 "RCs" to roll RC2.
> >
> > I think git can make this simpler. I would propose:
> >
> > -----X---------------------------- master
> > \
> > ----------------------- release-2.10.0
> > \ \ \
> > a b c
> > * X: same
> > * Y: gone
> > * On release branch, both Java and Python are -SNAPSHOT or dev, etc.
> > (and it could be release-2.10 that advances minor version in the commit
> > after a succesful RC)
> > * To build an RC, add the commits like a, b, c which remove -SNAPSHOT
> > and tag; we have a bash script that collects all the places that need
> > editing, the one that built commit X.
> > * Whether to push the commit and tag first or build the RC first
> > doesn't matter that much but anyhow now it is off the history so it is
> > fine to push.
> >
> > Have I missed something vital about the current process?
> >
> > Kenn
> >
> >
> >
> > On Thu, Jan 31, 2019 at 8:49 PM Thomas Weise <thw@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Either looks fine to me. Same content, different label :)
> >
> >
> > On Thu, Jan 31, 2019 at 6:32 PM Michael Luckey <adude3141@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Thx Thomas for that clarification. I tried to express, I d
> > slightly prefer to have branches
> >
> > 2.7.x
> > 2.8.x
> > 2.9.x
> >
> > and tags:
> > 2.7.0
> > 2.7.1
> > ...
> >
> > So only difference would be to be more explicit on the branch
> > name, i.e. that it embraces all the patch versions. (I do not
> > know how to better express, that '2.7.x' is a literal string and
> > should not be confused as some placeholder.)
> >
> > Regarding the versioning, I always prefer the explicit version
> > including patch version. It might make it easier to help and
> > resolve issues if it is known on which patch level a user is
> > running. I spent lot of lifetime assuming some version and
> > realising later it was 'just another snapshot' version...
> >
> > Just my 2 ct... Also fine with the previous suggestion.
> >
> >
> >
> > On Fri, Feb 1, 2019 at 3:18 AM Thomas Weise <thw@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Hi,
> >
> > As Kenn had already examplified, the suggestion was to have
> > branches:
> >
> > 2.7
> > 2.8
> > 2.9
> > ...
> >
> > and tags:
> >
> > 2.7.0
> > 2.7.1
> > ...
> > 2.8.0
> > ...
> >
> > Changes would go to the 2.7 branch, at some point release
> > 2.7.1 is created. Then more changes may accrue on the same
> > branch, maybe at some point 2.7.2 is released and so on.
> >
> > We could also consider changing the snapshot version to
> > 2.7-SNAPSHOT, instead of 2.7.{0,1,...}-SNAPSHOT.
> >
> > With that it wouldn't even be necessary to change the
> > version number on the branch.
> >
> > Thanks,
> > Thomas
> >
> >
> >
> > On Thu, Jan 31, 2019 at 5:59 PM Michael Luckey
> > <adude3141@gmail.com <ma...@gmail.com>> wrote:
> >
> > 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
> > <chamikara@google.com <ma...@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
> > <adude3141@gmail.com <ma...@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 <chamikara@google.com
> > <ma...@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 <klk@google.com
> > <ma...@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 <thw@apache.org
> > <ma...@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 <ccy@google.com
> > <ma...@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 <kenn@apache.org
> > <ma...@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
> > <mxm@apache.org
> > <ma...@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 <mxm@apache.org
> > <ma...@apache.org>
> > >
> > <mailto:mxm@apache.org
> > <ma...@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
> > <mxm@apache.org
> > <ma...@apache.org>
> > >
> > <mailto:mxm@apache.org
> > <ma...@apache.org>>
> > > >
> > <mailto:mxm@apache.org
> > <ma...@apache.org>
> > <mailto:mxm@apache.org
> > <mailto:mxm@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
> > > >
> > >
> >
>
Re: 2.7.1 (LTS) release?
Posted by Maximilian Michels <mx...@apache.org>.
Looks like a good improvement.
It makes sense to have the snapshot version on the release branch and
only change it to a proper version before creating the RC.
Do we still revert a, b, c after creating the RC? Otherwise the bash
script which replaces "-SNAPSHOT" won't work correctly.
-Max
On 06.02.19 20:21, Kenneth Knowles wrote:
> Having gone through the release process, I have a couple of git drawings
> to share. Currently the release process looks like this (you'll have to
> view in fixed width font if it is stripped by the mail manager).
>
> -----X---------------------------- master
> \
> ---Y-----a------b-------c----- release-2.10.0
>
> * X: commit that updates master from 2.10.0-SNAPSHOT to
> 2.11.0-SNAPSHOT (Python calls it 2.10.0dev, etc per lang, and we wrote a
> script for it)
> * The release branch starts the release branch from parent of X
> * Y: changes Python version to 2.10.0 (no dev) and you'll see why
> * On release branch, version is still 2.10.0-SNAPSHOT for Java
> * a, b, c: the gradle release plugin commits a change for Java to
> 2.10.0 then reverts it, and tags with RC1, RC2, RC3, etc. If the RC
> fails you have to force reset and delete the tag.
> * The release script also builds from fresh clones, so this is all
> pushed to GitHub. It can really clutter the history but is otherwise
> probably harmless. Because of issues with scripting and gpg set up I had
> to build maybe 10 "RCs" to roll RC2.
>
> I think git can make this simpler. I would propose:
>
> -----X---------------------------- master
> \
> ----------------------- release-2.10.0
> \ \ \
> a b c
> * X: same
> * Y: gone
> * On release branch, both Java and Python are -SNAPSHOT or dev, etc.
> (and it could be release-2.10 that advances minor version in the commit
> after a succesful RC)
> * To build an RC, add the commits like a, b, c which remove -SNAPSHOT
> and tag; we have a bash script that collects all the places that need
> editing, the one that built commit X.
> * Whether to push the commit and tag first or build the RC first
> doesn't matter that much but anyhow now it is off the history so it is
> fine to push.
>
> Have I missed something vital about the current process?
>
> Kenn
>
>
>
> On Thu, Jan 31, 2019 at 8:49 PM Thomas Weise <thw@apache.org
> <ma...@apache.org>> wrote:
>
> Either looks fine to me. Same content, different label :)
>
>
> On Thu, Jan 31, 2019 at 6:32 PM Michael Luckey <adude3141@gmail.com
> <ma...@gmail.com>> wrote:
>
> Thx Thomas for that clarification. I tried to express, I d
> slightly prefer to have branches
>
> 2.7.x
> 2.8.x
> 2.9.x
>
> and tags:
> 2.7.0
> 2.7.1
> ...
>
> So only difference would be to be more explicit on the branch
> name, i.e. that it embraces all the patch versions. (I do not
> know how to better express, that '2.7.x' is a literal string and
> should not be confused as some placeholder.)
>
> Regarding the versioning, I always prefer the explicit version
> including patch version. It might make it easier to help and
> resolve issues if it is known on which patch level a user is
> running. I spent lot of lifetime assuming some version and
> realising later it was 'just another snapshot' version...
>
> Just my 2 ct... Also fine with the previous suggestion.
>
>
>
> On Fri, Feb 1, 2019 at 3:18 AM Thomas Weise <thw@apache.org
> <ma...@apache.org>> wrote:
>
> Hi,
>
> As Kenn had already examplified, the suggestion was to have
> branches:
>
> 2.7
> 2.8
> 2.9
> ...
>
> and tags:
>
> 2.7.0
> 2.7.1
> ...
> 2.8.0
> ...
>
> Changes would go to the 2.7 branch, at some point release
> 2.7.1 is created. Then more changes may accrue on the same
> branch, maybe at some point 2.7.2 is released and so on.
>
> We could also consider changing the snapshot version to
> 2.7-SNAPSHOT, instead of 2.7.{0,1,...}-SNAPSHOT.
>
> With that it wouldn't even be necessary to change the
> version number on the branch.
>
> Thanks,
> Thomas
>
>
>
> On Thu, Jan 31, 2019 at 5:59 PM Michael Luckey
> <adude3141@gmail.com <ma...@gmail.com>> wrote:
>
> 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
> <chamikara@google.com <ma...@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
> <adude3141@gmail.com <ma...@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 <chamikara@google.com
> <ma...@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 <klk@google.com
> <ma...@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 <thw@apache.org
> <ma...@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 <ccy@google.com
> <ma...@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 <kenn@apache.org
> <ma...@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
> <mxm@apache.org
> <ma...@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 <mxm@apache.org
> <ma...@apache.org>
> >
> <mailto:mxm@apache.org
> <ma...@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
> <mxm@apache.org
> <ma...@apache.org>
> >
> <mailto:mxm@apache.org
> <ma...@apache.org>>
> > >
> <mailto:mxm@apache.org
> <ma...@apache.org>
> <mailto:mxm@apache.org
> <ma...@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
> > >
> >
>
Re: 2.7.1 (LTS) release?
Posted by Kenneth Knowles <kl...@google.com>.
Having gone through the release process, I have a couple of git drawings to
share. Currently the release process looks like this (you'll have to view
in fixed width font if it is stripped by the mail manager).
-----X---------------------------- master
\
---Y-----a------b-------c----- release-2.10.0
* X: commit that updates master from 2.10.0-SNAPSHOT to 2.11.0-SNAPSHOT
(Python calls it 2.10.0dev, etc per lang, and we wrote a script for it)
* The release branch starts the release branch from parent of X
* Y: changes Python version to 2.10.0 (no dev) and you'll see why
* On release branch, version is still 2.10.0-SNAPSHOT for Java
* a, b, c: the gradle release plugin commits a change for Java to 2.10.0
then reverts it, and tags with RC1, RC2, RC3, etc. If the RC fails you have
to force reset and delete the tag.
* The release script also builds from fresh clones, so this is all pushed
to GitHub. It can really clutter the history but is otherwise probably
harmless. Because of issues with scripting and gpg set up I had to build
maybe 10 "RCs" to roll RC2.
I think git can make this simpler. I would propose:
-----X---------------------------- master
\
----------------------- release-2.10.0
\ \ \
a b c
* X: same
* Y: gone
* On release branch, both Java and Python are -SNAPSHOT or dev, etc.
(and it could be release-2.10 that advances minor version in the commit
after a succesful RC)
* To build an RC, add the commits like a, b, c which remove -SNAPSHOT
and tag; we have a bash script that collects all the places that need
editing, the one that built commit X.
* Whether to push the commit and tag first or build the RC first doesn't
matter that much but anyhow now it is off the history so it is fine to push.
Have I missed something vital about the current process?
Kenn
On Thu, Jan 31, 2019 at 8:49 PM Thomas Weise <th...@apache.org> wrote:
> Either looks fine to me. Same content, different label :)
>
>
> On Thu, Jan 31, 2019 at 6:32 PM Michael Luckey <ad...@gmail.com>
> wrote:
>
>> Thx Thomas for that clarification. I tried to express, I d slightly
>> prefer to have branches
>>
>> 2.7.x
>> 2.8.x
>> 2.9.x
>>
>> and tags:
>> 2.7.0
>> 2.7.1
>> ...
>>
>> So only difference would be to be more explicit on the branch name, i.e.
>> that it embraces all the patch versions. (I do not know how to better
>> express, that '2.7.x' is a literal string and should not be confused as
>> some placeholder.)
>>
>> Regarding the versioning, I always prefer the explicit version including
>> patch version. It might make it easier to help and resolve issues if it is
>> known on which patch level a user is running. I spent lot of lifetime
>> assuming some version and realising later it was 'just another snapshot'
>> version...
>>
>> Just my 2 ct... Also fine with the previous suggestion.
>>
>>
>>
>> On Fri, Feb 1, 2019 at 3:18 AM Thomas Weise <th...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> As Kenn had already examplified, the suggestion was to have branches:
>>>
>>> 2.7
>>> 2.8
>>> 2.9
>>> ...
>>>
>>> and tags:
>>>
>>> 2.7.0
>>> 2.7.1
>>> ...
>>> 2.8.0
>>> ...
>>>
>>> Changes would go to the 2.7 branch, at some point release 2.7.1 is
>>> created. Then more changes may accrue on the same branch, maybe at some
>>> point 2.7.2 is released and so on.
>>>
>>> We could also consider changing the snapshot version to 2.7-SNAPSHOT,
>>> instead of 2.7.{0,1,...}-SNAPSHOT.
>>>
>>> With that it wouldn't even be necessary to change the version number on
>>> the branch.
>>>
>>> Thanks,
>>> Thomas
>>>
>>>
>>>
>>> On Thu, Jan 31, 2019 at 5:59 PM Michael Luckey <ad...@gmail.com>
>>> wrote:
>>>
>>>> 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 <ch...@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 <ad...@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 <
>>>>>> chamikara@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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <
>>>>>>>>>>> mxm@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 <
>>>>>>>>>>>> mxm@apache.org
>>>>>>>>>>>> > <ma...@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 <
>>>>>>>>>>>> mxm@apache.org
>>>>>>>>>>>> > <ma...@apache.org>
>>>>>>>>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>>>>>>>>> > >
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>
Re: 2.7.1 (LTS) release?
Posted by Thomas Weise <th...@apache.org>.
Either looks fine to me. Same content, different label :)
On Thu, Jan 31, 2019 at 6:32 PM Michael Luckey <ad...@gmail.com> wrote:
> Thx Thomas for that clarification. I tried to express, I d slightly prefer
> to have branches
>
> 2.7.x
> 2.8.x
> 2.9.x
>
> and tags:
> 2.7.0
> 2.7.1
> ...
>
> So only difference would be to be more explicit on the branch name, i.e.
> that it embraces all the patch versions. (I do not know how to better
> express, that '2.7.x' is a literal string and should not be confused as
> some placeholder.)
>
> Regarding the versioning, I always prefer the explicit version including
> patch version. It might make it easier to help and resolve issues if it is
> known on which patch level a user is running. I spent lot of lifetime
> assuming some version and realising later it was 'just another snapshot'
> version...
>
> Just my 2 ct... Also fine with the previous suggestion.
>
>
>
> On Fri, Feb 1, 2019 at 3:18 AM Thomas Weise <th...@apache.org> wrote:
>
>> Hi,
>>
>> As Kenn had already examplified, the suggestion was to have branches:
>>
>> 2.7
>> 2.8
>> 2.9
>> ...
>>
>> and tags:
>>
>> 2.7.0
>> 2.7.1
>> ...
>> 2.8.0
>> ...
>>
>> Changes would go to the 2.7 branch, at some point release 2.7.1 is
>> created. Then more changes may accrue on the same branch, maybe at some
>> point 2.7.2 is released and so on.
>>
>> We could also consider changing the snapshot version to 2.7-SNAPSHOT,
>> instead of 2.7.{0,1,...}-SNAPSHOT.
>>
>> With that it wouldn't even be necessary to change the version number on
>> the branch.
>>
>> Thanks,
>> Thomas
>>
>>
>>
>> On Thu, Jan 31, 2019 at 5:59 PM Michael Luckey <ad...@gmail.com>
>> wrote:
>>
>>> 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 <ch...@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 <ad...@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 <
>>>>> chamikara@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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <
>>>>>>>>>> mxm@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 <
>>>>>>>>>>> mxm@apache.org
>>>>>>>>>>> > <ma...@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 <
>>>>>>>>>>> mxm@apache.org
>>>>>>>>>>> > <ma...@apache.org>
>>>>>>>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>>>>>>>> > >
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>
Re: 2.7.1 (LTS) release?
Posted by Michael Luckey <ad...@gmail.com>.
Thx Thomas for that clarification. I tried to express, I d slightly prefer
to have branches
2.7.x
2.8.x
2.9.x
and tags:
2.7.0
2.7.1
...
So only difference would be to be more explicit on the branch name, i.e.
that it embraces all the patch versions. (I do not know how to better
express, that '2.7.x' is a literal string and should not be confused as
some placeholder.)
Regarding the versioning, I always prefer the explicit version including
patch version. It might make it easier to help and resolve issues if it is
known on which patch level a user is running. I spent lot of lifetime
assuming some version and realising later it was 'just another snapshot'
version...
Just my 2 ct... Also fine with the previous suggestion.
On Fri, Feb 1, 2019 at 3:18 AM Thomas Weise <th...@apache.org> wrote:
> Hi,
>
> As Kenn had already examplified, the suggestion was to have branches:
>
> 2.7
> 2.8
> 2.9
> ...
>
> and tags:
>
> 2.7.0
> 2.7.1
> ...
> 2.8.0
> ...
>
> Changes would go to the 2.7 branch, at some point release 2.7.1 is
> created. Then more changes may accrue on the same branch, maybe at some
> point 2.7.2 is released and so on.
>
> We could also consider changing the snapshot version to 2.7-SNAPSHOT,
> instead of 2.7.{0,1,...}-SNAPSHOT.
>
> With that it wouldn't even be necessary to change the version number on
> the branch.
>
> Thanks,
> Thomas
>
>
>
> On Thu, Jan 31, 2019 at 5:59 PM Michael Luckey <ad...@gmail.com>
> wrote:
>
>> 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 <ch...@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 <ad...@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 <ch...@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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <mx...@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 <
>>>>>>>>>> mxm@apache.org
>>>>>>>>>> > <ma...@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 <
>>>>>>>>>> mxm@apache.org
>>>>>>>>>> > <ma...@apache.org>
>>>>>>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>>>>>>> > >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
Re: 2.7.1 (LTS) release?
Posted by Thomas Weise <th...@apache.org>.
Hi,
As Kenn had already examplified, the suggestion was to have branches:
2.7
2.8
2.9
...
and tags:
2.7.0
2.7.1
...
2.8.0
...
Changes would go to the 2.7 branch, at some point release 2.7.1 is created.
Then more changes may accrue on the same branch, maybe at some point 2.7.2
is released and so on.
We could also consider changing the snapshot version to 2.7-SNAPSHOT,
instead of 2.7.{0,1,...}-SNAPSHOT.
With that it wouldn't even be necessary to change the version number on the
branch.
Thanks,
Thomas
On Thu, Jan 31, 2019 at 5:59 PM Michael Luckey <ad...@gmail.com> wrote:
> 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 <ch...@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 <ad...@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 <ch...@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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <mx...@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 <
>>>>>>>>> mxm@apache.org
>>>>>>>>> > <ma...@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 <
>>>>>>>>> mxm@apache.org
>>>>>>>>> > <ma...@apache.org>
>>>>>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>>>>>> > >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
Re: 2.7.1 (LTS) release?
Posted by Michael Luckey <ad...@gmail.com>.
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 <ch...@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 <ad...@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 <ch...@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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <mx...@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 <
>>>>>>>> mxm@apache.org
>>>>>>>> > <ma...@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 <
>>>>>>>> mxm@apache.org
>>>>>>>> > <ma...@apache.org>
>>>>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>>>>> > >
>>>>>>>> >
>>>>>>>>
>>>>>>>
Re: 2.7.1 (LTS) release?
Posted by Chamikara Jayalath <ch...@google.com>.
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 <ad...@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 <ch...@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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <mx...@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 <mxm@apache.org
>>>>>>> > <ma...@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 <
>>>>>>> mxm@apache.org
>>>>>>> > <ma...@apache.org>
>>>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
Re: 2.7.1 (LTS) release?
Posted by Michael Luckey <ad...@gmail.com>.
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 <ch...@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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <mx...@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 <mxm@apache.org
>>>>>> > <ma...@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 <
>>>>>> mxm@apache.org
>>>>>> > <ma...@apache.org>
>>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
Re: 2.7.1 (LTS) release?
Posted by Chamikara Jayalath <ch...@google.com>.
+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 <kl...@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 <th...@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 <cc...@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 <ke...@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 <mx...@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 <mxm@apache.org
>>>>> > <ma...@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 <
>>>>> mxm@apache.org
>>>>> > <ma...@apache.org>
>>>>> > > <mailto:mxm@apache.org <ma...@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
>>>>> > >
>>>>> >
>>>>>
>>>>
Re: 2.7.1 (LTS) release?
Posted by Kenneth Knowles <kl...@google.com>.
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 <th...@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 <cc...@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 <ke...@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 <mx...@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 <mxm@apache.org
>>>> > <ma...@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 <
>>>> mxm@apache.org
>>>> > <ma...@apache.org>
>>>> > > <mailto:mxm@apache.org <ma...@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
>>>> > >
>>>> >
>>>>
>>>
Re: 2.7.1 (LTS) release?
Posted by Thomas Weise <th...@apache.org>.
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 <cc...@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 <ke...@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 <mx...@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 <mxm@apache.org
>>> > <ma...@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 <
>>> mxm@apache.org
>>> > <ma...@apache.org>
>>> > > <mailto:mxm@apache.org <ma...@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
>>> > >
>>> >
>>>
>>
Re: 2.7.1 (LTS) release?
Posted by Charles Chen <cc...@google.com>.
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 <ke...@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 <mx...@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 <mxm@apache.org
>> > <ma...@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 <
>> mxm@apache.org
>> > <ma...@apache.org>
>> > > <mailto:mxm@apache.org <ma...@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
>> > >
>> >
>>
>
Re: 2.7.1 (LTS) release?
Posted by Kenneth Knowles <ke...@apache.org>.
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 <mx...@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 <mxm@apache.org
> > <ma...@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 <
> mxm@apache.org
> > <ma...@apache.org>
> > > <mailto:mxm@apache.org <ma...@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
> > >
> >
>
Re: 2.7.1 (LTS) release?
Posted by Maximilian Michels <mx...@apache.org>.
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 <mxm@apache.org
> <ma...@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 <mxm@apache.org
> <ma...@apache.org>
> > <mailto:mxm@apache.org <ma...@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
> >
>
Re: 2.7.1 (LTS) release?
Posted by Thomas Weise <th...@apache.org>.
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 <mx...@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 <mxm@apache.org
> > <ma...@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
> >
>
Re: 2.7.1 (LTS) release?
Posted by Maximilian Michels <mx...@apache.org>.
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 <mxm@apache.org
> <ma...@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
>
Re: 2.7.1 (LTS) release?
Posted by Kenneth Knowles <ke...@apache.org>.
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 <mx...@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
>