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 <t...@apache.org> wrote:
> 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
>>>>>>>>>>>> > >
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>
