+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 <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > Either looks fine to me. Same content, different label :) > > > > > > On Thu, Jan 31, 2019 at 6:32 PM Michael Luckey <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 > > <[email protected] <mailto:[email protected]>> 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 > > <[email protected] <mailto:[email protected]>> > 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 > > <[email protected] <mailto:[email protected]>> > > 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 > > <[email protected] > > <mailto:[email protected]>> > 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 <[email protected] > > <mailto:[email protected]> > > > > > <mailto:[email protected] > > <mailto:[email protected]>>> > 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 > > <[email protected] > > <mailto:[email protected]> > > > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > > > <mailto:[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected] > >>>> > > 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 > > > > > > > > > >
