Either looks fine to me. Same content, different label :)
On Thu, Jan 31, 2019 at 6:32 PM Michael Luckey <adude3...@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 <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
>>>>>>>>>>> > >
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>
