hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-14025) Update CHANGES.txt for 1.2
Date Sat, 18 Jun 2016 02:56:05 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337460#comment-15337460
] 

Sean Busbey edited comment on HBASE-14025 at 6/18/16 2:55 AM:
--------------------------------------------------------------

{quote}
if we're considering the Jira to be a source of truth here, then "project = HBase AND fixVersion
= 1.3.0 AND fixVersion not in (1.2.0, 1.2.1, 1.2.2) AND status in (Resolved, Closed) ORDER
BY issuetype DESC, updated ASC" jira filter should basically give the list of jiras (if we
assumed that fixVersion are set accurately), if the jira fixVersion was always accurate?
{quote}

I would just look at those jiras with fixVersion 1.3.0 and fixVersion not in 1.2.0, 1.1.0,
1.0.0. After the .0 release, it's hard to know how maintenance releases in the prior minor
release line marry up with the new minor release line.

{quote}
bq. "find the commit where your release line branched off from the previous release.
bq. $ git merge-base 1.1.0 branch-1.2
bq. 8166142b2e815fc6ab30c14a5a546cd242bf3b4c"
But branch-1.3 was cut off branch-1 with whatever was there in the moment, so I don't see
how it applies?
{quote}

right, but the prior minor release lines were also cut off of it. you can find where the branch
for the prior minor release left branch-1 using merge-base, which then lets you check the
commits that continued on branch-1 afterwards to see which ones also made it into the prior
minor release.

That is, after the branch that led to 1.2.0 came off of branch-1 some set of JIRAS still had
commits on both branches. the ones that happened on both you need not include in the CHANGES
file for 1.3.0 because they will already be listed under 1.2.0.

does that make sense? If not, could make a diagram maybe?



was (Author: busbey):
{quote}
if we're considering the Jira to be a source of truth here, then "project = HBase AND fixVersion
= 1.3.0 AND fixVersion not in (1.2.0, 1.2.1, 1.2.2) AND status in (Resolved, Closed) ORDER
BY issuetype DESC, updated ASC" jira filter should basically give the list of jiras (if we
assumed that fixVersion are set accurately), if the jira fixVersion was always accurate?
{quote}

I would just look at those jiras with fixVersion 1.3.0 and fixVersion not in 1.2.0, 1.1.0,
1.0.0. After the .0 release, it's hard to know how maintenance releases in the prior minor
release line marry up with the new minor release line.

{quote}
bq. "find the commit where your release line branched off from the previous release.
$ git merge-base 1.1.0 branch-1.2
8166142b2e815fc6ab30c14a5a546cd242bf3b4c"
But branch-1.3 was cut off branch-1 with whatever was there in the moment, so I don't see
how it applies?
{quote}

right, but the prior minor release lines were also cut off of it. you can find where the branch
for the prior minor release left branch-1 using merge-base, which then lets you check the
commits that continued on branch-1 afterwards to see which ones also made it into the prior
minor release.

That is, after the branch that led to 1.2.0 came off of branch-1 some set of JIRAS still had
commits on both branches. the ones that happened on both you need not include in the CHANGES
file for 1.3.0 because they will already be listed under 1.2.0.

does that make sense? If not, could make a diagram maybe?


> Update CHANGES.txt for 1.2
> --------------------------
>
>                 Key: HBASE-14025
>                 URL: https://issues.apache.org/jira/browse/HBASE-14025
>             Project: HBase
>          Issue Type: Sub-task
>          Components: documentation
>    Affects Versions: 1.2.0
>            Reporter: Sean Busbey
>            Assignee: Sean Busbey
>             Fix For: 1.2.0
>
>
> Since it's more effort than I expected, making a ticket to track actually updating CHANGES.txt
so that new RMs have an idea what to expect.
> Maybe will make doc changes if there's enough here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message