Thanks Andrew for sharing your thoughts,
It looks better if we can put multiple versions on the fix version, with
that we can at least do some queries on JIRA to check the issues like "in
branch-2.6.5 but not in branch-2.7.4".
I still have a couple of questions:
*1) How CHANGES.txt (or release note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.
For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.
However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.
To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.
Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.
*2) Do we need to update historical JIRAs?*
It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.
Thoughts?
Wangda
On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <andrew.w...@cloudera.com>
wrote:
> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > Andrew: I bet many would assume it's the release date, like how Ubuntu
> > releases are numbered.
> >
> > Good point. Maybe I confuse you because of lack of explanation.
> >
> > I assume that "branch-cut off timing" mean the timing of freezing branch
> > like when starting the release vote. It's because that the release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <andrew.w...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
> we
> >>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and
> we
> >>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a
> jira.
> >>> Is it right?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>
