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 <[email protected]> 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 <[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 >> > > > >> > > >> > >> >
