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 <t...@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 <adude3...@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 <chamik...@google.com>
>> wrote:
>>
>>> Sorry, what I meant was branches+tags for each minor version release and
>>> adding updates and tags to the same branch for patch releases. Name of the
>>> branch can be release-2.X for minor version release 2.X.0 as Thomas
>>> mentioned.
>>>
>>> - Cham
>>>
>>> On Thu, Jan 31, 2019 at 5:46 PM Michael Luckey <adude3...@gmail.com>
>>> wrote:
>>>
>>>> Maybe we should not go so far to name branches 2.x. This will probably
>>>> make it difficult to support more than 1 LTS. Don't know, whether we ever
>>>> intent to do so, but supporting 2.7 and 2.13 on a 2.x branch seems
>>>> difficult?
>>>>
>>>> A more explicit 2.7.x with tags 2.7.1, 2.7.2 etc might be better? If we
>>>> are going to support a second LTS later on, we could just add that 2.??.x
>>>> branch.
>>>>
>>>> michel
>>>>
>>>> On Fri, Feb 1, 2019 at 2:37 AM Chamikara Jayalath <chamik...@google.com>
>>>> wrote:
>>>>
>>>>> +1 for 2.x branches and tags for 2.x.y releases.
>>>>>
>>>>> Also, I think we should integrate the dependency upgrade
>>>>> https://issues.apache.org/jira/browse/BEAM-6552 to 2.7.1 which fixes
>>>>> a rare but critical bug.
>>>>>
>>>>> Thanks,
>>>>> Cham
>>>>>
>>>>> On Thu, Jan 31, 2019 at 12:17 PM Kenneth Knowles <k...@google.com>
>>>>> wrote:
>>>>>
>>>>>> It makes sense to me that 2.7 is a branch and just tags for 2.7.0,
>>>>>> 2.7.1, etc.
>>>>>>
>>>>>> On Thu, Jan 31, 2019 at 11:43 AM Thomas Weise <t...@apache.org> wrote:
>>>>>>
>>>>>>> How about naming the branches release-X.Y and use them as base for
>>>>>>> all the X.Y.Z releases? We already have the X.Y.Z tags to refer to the
>>>>>>> actual release.
>>>>>>>
>>>>>>> On Thu, Jan 31, 2019 at 11:23 AM Charles Chen <c...@google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I would be in favor of keeping the old 2.7.0 release branch / tag
>>>>>>>> static so that referring to it will always get the right 2.7.0 code.
>>>>>>>>
>>>>>>>> On Thu, Jan 31, 2019 at 10:24 AM Kenneth Knowles <k...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I have waffled on whether to have release-2.7 and only branch
>>>>>>>>> release-2.7.1 when starting that release. I think that whenever we
>>>>>>>>> release
>>>>>>>>> 2.7.n the branch for 2.7.(n+1) should start from exactly that point,
>>>>>>>>> no? Or
>>>>>>>>> perhaps on release-2.7 branch the hardcoded version strings could be
>>>>>>>>> 2.7.1-SNAPSHOT/dev and remove the SNAPSHOT/dev when cutting the new
>>>>>>>>> release
>>>>>>>>> branch? I guess I think either one is fine. I think starting the
>>>>>>>>> branch now
>>>>>>>>> is smart, so that you can accumulate cherrypicks of backports.
>>>>>>>>>
>>>>>>>>> Kenn
>>>>>>>>>
>>>>>>>>> On Thu, Jan 31, 2019 at 7:55 AM Maximilian Michels <m...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 2.10.0 will be done when its done. Same goes for 2.7.1, which is
>>>>>>>>>> likely going to
>>>>>>>>>> be done later since we are focusing on 2.10.0 at the moment.
>>>>>>>>>>
>>>>>>>>>> I've created the release-2.7.1 branch because there is no other
>>>>>>>>>> place for fixes
>>>>>>>>>> of future versions. It would be helpful to have a minor version
>>>>>>>>>> branch (e.g.
>>>>>>>>>> release-2.7) which can be continuously updated.
>>>>>>>>>>
>>>>>>>>>> More generally speaking, we should dedicate time for LTS
>>>>>>>>>> releases. What is the
>>>>>>>>>> point otherwise of having an LTS version?
>>>>>>>>>>
>>>>>>>>>> -Max
>>>>>>>>>>
>>>>>>>>>> On 31.01.19 16:28, Thomas Weise wrote:
>>>>>>>>>> > Since you were originally thinking of 2.9.x as target, 2.10.0
>>>>>>>>>> seems closer both
>>>>>>>>>> > in time and upgrade path.
>>>>>>>>>> >
>>>>>>>>>> > I see no reason why a 2.7.1 release would materialize any
>>>>>>>>>> sooner than 2.10.0.
>>>>>>>>>> >
>>>>>>>>>> > Or is the intention is to just stack up fixes in the 2.7.x
>>>>>>>>>> branch for a
>>>>>>>>>> > potential future release?
>>>>>>>>>> >
>>>>>>>>>> > Thomas
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > On Thu, Jan 31, 2019 at 5:03 AM Maximilian Michels <
>>>>>>>>>> m...@apache.org
>>>>>>>>>> > <mailto:m...@apache.org>> wrote:
>>>>>>>>>> >
>>>>>>>>>> > I agree it's better to take some extra time to ensure the
>>>>>>>>>> quality of 2.10.0.
>>>>>>>>>> >
>>>>>>>>>> > I've created a 2.7.1 branch and cherry-picked the relevant
>>>>>>>>>> commits[1]. We could
>>>>>>>>>> > start collecting other fixes in case there are any.
>>>>>>>>>> >
>>>>>>>>>> > -Max
>>>>>>>>>> >
>>>>>>>>>> > [1] https://github.com/apache/beam/pull/7687
>>>>>>>>>> >
>>>>>>>>>> > On 30.01.19 20:57, Kenneth Knowles wrote:
>>>>>>>>>> > > Sounds good to me to target 2.7.1 and 2.10.0. I will
>>>>>>>>>> have to re-roll RC2
>>>>>>>>>> > after
>>>>>>>>>> > > confirming fixes for the latest blockers that were
>>>>>>>>>> found. These are not
>>>>>>>>>> > > regressions from 2.9.0. But they seem severe enough that
>>>>>>>>>> they are worth
>>>>>>>>>> > taking
>>>>>>>>>> > > an extra day or two, because 2.9.0 had enough problems
>>>>>>>>>> that I would like
>>>>>>>>>> > to make
>>>>>>>>>> > > 2.10.0 a more attractive upgrade target for users still
>>>>>>>>>> on very old versions.
>>>>>>>>>> > >
>>>>>>>>>> > > Kenn
>>>>>>>>>> > >
>>>>>>>>>> > > On Wed, Jan 30, 2019 at 5:22 AM Maximilian Michels <
>>>>>>>>>> m...@apache.org
>>>>>>>>>> > <mailto:m...@apache.org>
>>>>>>>>>> > > <mailto:m...@apache.org <mailto:m...@apache.org>>> wrote:
>>>>>>>>>> > >
>>>>>>>>>> > > Hi everyone,
>>>>>>>>>> > >
>>>>>>>>>> > > I know we are in the midst of releasing 2.10.0, but
>>>>>>>>>> with the release
>>>>>>>>>> > process
>>>>>>>>>> > > taking its time I consider creating a patch release
>>>>>>>>>> for this issue in the
>>>>>>>>>> > > FlinkRunner:
>>>>>>>>>> https://jira.apache.org/jira/browse/BEAM-5386
>>>>>>>>>> > >
>>>>>>>>>> > > Initially I thought it would be good to do a 2.9.1
>>>>>>>>>> release, but since we
>>>>>>>>>> > > have an
>>>>>>>>>> > > LTS version, we should probably do a 2.7.1 (LTS)
>>>>>>>>>> release instead.
>>>>>>>>>> > >
>>>>>>>>>> > > What do you think? I could only find one Fix Version
>>>>>>>>>> 2.7.1 issue in JIRA:
>>>>>>>>>> > >
>>>>>>>>>> >
>>>>>>>>>> https://jira.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20fixVersion%20%3D%202.7.1
>>>>>>>>>> > >
>>>>>>>>>> > > Best,
>>>>>>>>>> > > Max
>>>>>>>>>> > >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
