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
<mailto: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
<mailto: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
<mailto: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 <mailto: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 <mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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>
>
<mailto: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>>
> >
<mailto: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
> >
>
