You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Sean Busbey (JIRA)" <ji...@apache.org> on 2016/06/18 02:56:05 UTC

[jira] [Comment Edited] (HBASE-14025) Update CHANGES.txt for 1.2

    [ 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)