I can confirm there are a few things committed to branch-1 not in branch-1.4 now. Fix versions are set accordingly (1.5.0 is in the set, 1.4.0 is not)
On Fri, Nov 10, 2017 at 5:38 AM, Sean Busbey <[email protected]> wrote: > 1.5.0 needs to appear already since a) we need a place to target fixes > that we're booting out of 1.4.0 and b) branch-1 and branch-1.4 have > diverged so a fix in one does not necessarily mean a fix is in the > other. > > On Thu, Nov 9, 2017 at 11:50 PM, Yu Li <[email protected]> wrote: > > It would be a pain for user to judge whether a patch for 1.3.1 is > included > > in 1.4.0 from the version number, they will have to get and compare the > > release timeline of 1.3.1 and 1.4.0. So I'm a big fun of the already > taken > > action: "Now, 1.4.0 was dropped only if there is a fixversion 1.3.0 in > the > > set" > > > > bq. For example, don't mark 'fixed in 1.5' on the JIRA until 1.4.0 is out > > I'm not that sure but it seems to me 1.5 shouldn't appear in the "Fix > > version" options before 1.4.0 is out? > > > > Best Regards, > > Yu > > > > On 10 November 2017 at 08:19, Jerry He <[email protected]> wrote: > > > >> It is a good discussion. I had confusions in rare cases where I > couldn't > >> rely on the JIRA clearly if a fix was in a release. It will be really > nice > >> to explicitly document the implicit assumptions. > >> > >> Is there anything or change that committers need to do? For example, > don't > >> mark 'fixed in 1.5' on the JIRA until 1.4.0 is out, and don't mark 3.0 > >> until 2.0 is out? Or it will be up to RMs' batch job? > >> > >> Thanks. > >> > >> Jerry > >> > >> On Thu, Nov 9, 2017 at 12:37 PM Stack <[email protected]> wrote: > >> > >> > On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <[email protected]> wrote: > >> > > >> > > By this same token, there are a lot of issues with fix version > >> > 2.0.0-alphaX > >> > > or -betaY and also 3.0.0 > >> > > > >> > > Should we drop the 3.0.0 from these? > >> > > > >> > > > >> > Yes (says the 2.0.0 RM). I've been doing this as I come across them. > >> > > >> > I filed HBASE-19230 to write-up what we've said out loud about our > >> practice > >> > here. > >> > > >> > St.Ack > >> > > >> > > >> > > >> > > >> > > >> > > On Thu, Nov 9, 2017 at 1:42 PM, Andrew Purtell <[email protected] > > > >> > > wrote: > >> > > > >> > > > > once 1.4.0 RC0 comes out, we need to include 1.5.0 because if > RC0 > >> > > passes, > >> > > > such an issue will actually be in 1.4.1 and not 1.4.0 > >> > > > > >> > > > Ok, I'll remember that. > >> > > > > >> > > > > >> > > > On Thu, Nov 9, 2017 at 11:40 AM, Sean Busbey <[email protected]> > >> > wrote: > >> > > > > >> > > > > That all sounds correct. The one edge case is that when the .0 > >> > release > >> > > > > hasn't been cut yet but RCs exist, it's important to include in > fix > >> > > > > versions any releases that would need to be included if the > current > >> > RC > >> > > > > passed. > >> > > > > > >> > > > > e.g. once 1.4.0 RC0 comes out, we need to include 1.5.0 because > if > >> > RC0 > >> > > > > passes, such an issue will actually be in 1.4.1 and not 1.4.0. > I'm > >> > not > >> > > > > sure if we should set 1.4.0 or 1.4.1 in such a case. When > prepping > >> > for > >> > > > > 1.2.0 I tried to account for folks who had picked either 1.2.0 > or > >> > > > > 1.2.1 when generating the next RC, by correcting fix versions as > >> > > > > needed. > >> > > > > > >> > > > > On Thu, Nov 9, 2017 at 1:28 PM, Dave Latham < > [email protected]> > >> > > wrote: > >> > > > > > Cool. Don't mean to suggest this is a change or new, just > >> thinking > >> > > > > through > >> > > > > > and writing down what I think I've observed and folks seem to > be > >> > > doing, > >> > > > > > which makes sense. > >> > > > > > I don't have the bandwidth at the moment to figure out the doc > >> > format > >> > > > and > >> > > > > > go through the process to create a patch, but if any of the > above > >> > is > >> > > > > > helpful, would be happy for anyone inclined to get it into the > >> doc. > >> > > > > > > >> > > > > > On Thu, Nov 9, 2017 at 11:24 AM, Andrew Purtell < > >> > [email protected] > >> > > > > >> > > > > wrote: > >> > > > > > > >> > > > > >> > Yes, those are the rules I applied. > >> > > > > >> > >> > > > > >> To clarify: Those are the rules I applied after going back > and > >> > > adding > >> > > > > back > >> > > > > >> fixversions such that the set {1.3.1, ...} becomes {1.4.0, > >> 1.3.1, > >> > > ...} > >> > > > > as > >> > > > > >> Sean suggested. > >> > > > > >> > >> > > > > >> Now, 1.4.0 was dropped only if there is a fixversion 1.3.0 in > >> the > >> > > set. > >> > > > > And, > >> > > > > >> 1.5.0 was dropped wherever we have 1.4.0 in the set, and > that > >> is > >> > > > > currently > >> > > > > >> everywhere because at this moment branch-1.4 == branch-1, but > >> will > >> > > > > begin to > >> > > > > >> diverge as soon as 1.4.0 is released. > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> On Thu, Nov 9, 2017 at 11:21 AM, Andrew Purtell < > >> > > [email protected]> > >> > > > > >> wrote: > >> > > > > >> > >> > > > > >> > Yes, those are the rules I applied. > >> > > > > >> > > >> > > > > >> > While I was in there adjusting fixversions I noticed that > >> > > generally > >> > > > we > >> > > > > >> > follow exactly that approach for numbering. I think we > inherit > >> > it > >> > > > from > >> > > > > >> > Hadoop, because our old timers came from that community. > >> > > > > >> > > >> > > > > >> > Dave - Please consider submitting a patch for our online > book > >> > for > >> > > > > this, > >> > > > > >> if > >> > > > > >> > the text doesn't already exist in there somewhere. > >> > > > > >> > > >> > > > > >> > On Thu, Nov 9, 2017 at 11:17 AM, Dave Latham < > >> > [email protected] > >> > > > > >> > > > > >> wrote: > >> > > > > >> > > >> > > > > >> >> +1 for making it as simple as possible to determine if a > >> given > >> > > fix > >> > > > is > >> > > > > >> in a > >> > > > > >> >> given release purely from the release numbers, without > having > >> > to > >> > > > > consult > >> > > > > >> >> the dates of when branches were made or release candidates > >> were > >> > > > > built. > >> > > > > >> >> > >> > > > > >> >> I think the rules should be > >> > > > > >> >> > >> > > > > >> >> Fix version of X.Y.Z => fixed in all releases X.Y.Z' > where Z' > >> > >= > >> > > Z > >> > > > > >> >> Fix version of X.Y.0 => fixed in all releases X.Y'.* > where Y' > >> > >= > >> > > Y > >> > > > > >> >> Fix version of X.0.0 => fixed in all releases X'.*.* > where X' > >> > >= > >> > > X > >> > > > > >> >> > >> > > > > >> >> By this policy, fix version of 1.3.0 implies 1.4.0, but > 1.3.2 > >> > > does > >> > > > > not > >> > > > > >> >> imply 1.4.0, as we could not tell purely from the numbers > >> which > >> > > > > release > >> > > > > >> >> came first. > >> > > > > >> >> > >> > > > > >> >> To track a fix then, I think that means that there should > >> > usually > >> > > > be > >> > > > > a > >> > > > > >> fix > >> > > > > >> >> version added for each branch that a commit was pushed to, > >> with > >> > > the > >> > > > > >> >> exception of master if there is a branch for the next > major > >> > > release > >> > > > > that > >> > > > > >> >> has not happened yet. > >> > > > > >> >> > >> > > > > >> >> I think this is probably just repeating what Sean was > saying, > >> > but > >> > > > it > >> > > > > was > >> > > > > >> >> helpful for me to write out and perhaps helpful for > others to > >> > > think > >> > > > > >> about. > >> > > > > >> >> > >> > > > > >> >> On Thu, Nov 9, 2017 at 10:37 AM, Andrew Purtell < > >> > > > [email protected] > >> > > > > > > >> > > > > >> >> wrote: > >> > > > > >> >> > >> > > > > >> >> > Related, on HBASE-18996 Peter said: > >> > > > > >> >> > > >> > > > > >> >> > the fix version is not correct. It should include 1.5 > too. > >> > Did > >> > > > you > >> > > > > >> >> remove > >> > > > > >> >> > that on purpose? > >> > > > > >> >> > > >> > > > > >> >> > and my response: > >> > > > > >> >> > > >> > > > > >> >> > Yes, I removed 1.5.0 for anything that is going out in > >> 1.4.0. > >> > > Fix > >> > > > > >> >> versions > >> > > > > >> >> > in HBase have historically meant the same thing as in > >> Hadoop, > >> > > > > which is > >> > > > > >> >> "in > >> > > > > >> >> > this release and any later". That said, I'm only > touching > >> fix > >> > > > > versions > >> > > > > >> >> for > >> > > > > >> >> > branch-1. I won't presume to mess with fix version > >> accounting > >> > > for > >> > > > > >> >> branch-2. > >> > > > > >> >> > We have another RM tending to that. > >> > > > > >> >> > At this point branch-1 (1.5.0) == branch-1.4 (1.4.0) so > >> > having > >> > > > both > >> > > > > >> in > >> > > > > >> >> > fixversions would be fine but redundant, and a future RM > >> > would > >> > > > have > >> > > > > >> some > >> > > > > >> >> > work to do. As things stood, they were horribly > >> inconsistent, > >> > > > with > >> > > > > >> many > >> > > > > >> >> > 1.5.0 fixversions missing. > >> > > > > >> >> > > >> > > > > >> >> > > >> > > > > >> >> > On Thu, Nov 9, 2017 at 10:27 AM, Andrew Purtell < > >> > > > > [email protected]> > >> > > > > >> >> > wrote: > >> > > > > >> >> > > >> > > > > >> >> > > You mean put back the 1.4.0 fixversion for anything > >> > released > >> > > in > >> > > > > >> >> 1.3.1? I > >> > > > > >> >> > > can do that. I don't have a strong opinion either way. > >> Let > >> > me > >> > > > > make a > >> > > > > >> >> pass > >> > > > > >> >> > > now. > >> > > > > >> >> > > > >> > > > > >> >> > > Any other suggestions? > >> > > > > >> >> > > > >> > > > > >> >> > > > >> > > > > >> >> > > On Thu, Nov 9, 2017 at 6:15 AM, Sean Busbey < > >> > > [email protected] > >> > > > > > >> > > > > >> >> wrote: > >> > > > > >> >> > > > >> > > > > >> >> > >> I'd like to try convincing you to just drop issues > that > >> > were > >> > > > in > >> > > > > >> >> 1.3.0. > >> > > > > >> >> > >> > >> > > > > >> >> > >> I assume that 1.4 will become our new stable line. > >> Suppose > >> > > > that > >> > > > > I > >> > > > > >> am > >> > > > > >> >> > >> running on our stable 1.2 release line. When > considering > >> > an > >> > > > > upgrade > >> > > > > >> >> to > >> > > > > >> >> > >> 1.4.z, which CHANGES files do I have to read to get a > >> > sense > >> > > of > >> > > > > >> what I > >> > > > > >> >> > >> have to look out for in changes? > >> > > > > >> >> > >> > >> > > > > >> >> > >> Presuming the 1.3.0 CHANGES files contains everything > >> that > >> > > > > changed > >> > > > > >> >> > >> since 1.2.0, I could just read the 1.3.0 CHANGES and > >> then > >> > > the > >> > > > > >> CHANGE > >> > > > > >> >> > >> for the 1.4.z release I am aiming for (since it will > >> have > >> > > > 1.4.0 > >> > > > > - > >> > > > > >> >> > >> 1.4.z in it). > >> > > > > >> >> > >> > >> > > > > >> >> > >> If you use a later 1.3.z as the basis, then I have to > >> find > >> > > > what > >> > > > > the > >> > > > > >> >> > >> last 1.3.z that had its RC created before 1.4.0. (a > >> later > >> > > one > >> > > > > will > >> > > > > >> >> > >> cover changes that are not included in 1.4.0 and > might > >> not > >> > > be > >> > > > in > >> > > > > >> any > >> > > > > >> >> > >> 1.4.z yet) > >> > > > > >> >> > >> > >> > > > > >> >> > >> On Thu, Nov 9, 2017 at 12:05 AM, Stack < > >> [email protected]> > >> > > > > wrote: > >> > > > > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell < > >> > > > > >> >> [email protected]> > >> > > > > >> >> > >> wrote: > >> > > > > >> >> > >> > > >> > > > > >> >> > >> >> You may notice I'm dropping '1.4.0' from fix > versions > >> > > > > wherever > >> > > > > >> we > >> > > > > >> >> > have > >> > > > > >> >> > >> >> something that went in to any 1.3.x. This is > because > >> I > >> > am > >> > > > > basing > >> > > > > >> >> the > >> > > > > >> >> > >> >> CHANGES.txt changelog for 1.4.0 on the latest from > >> > > > > branch-1.3, > >> > > > > >> so > >> > > > > >> >> > >> anything > >> > > > > >> >> > >> >> that went in on branch-1.3 will be included in the > >> > > > changelog > >> > > > > at > >> > > > > >> >> the > >> > > > > >> >> > >> correct > >> > > > > >> >> > >> >> point in history. Anything in the 1.4.0 section of > >> the > >> > > > > changelog > >> > > > > >> >> for > >> > > > > >> >> > >> >> branch-1.4 will be for changes in branch-1.4 not > in > >> > > > > branch-1.3. > >> > > > > >> >> > >> >> > >> > > > > >> >> > >> >> > >> > > > > >> >> > >> > If 1.4.0 goes out before 1.3.2, does that mean, > there > >> > will > >> > > > be > >> > > > > >> fixes > >> > > > > >> >> > that > >> > > > > >> >> > >> > are in 1.4.0 (because they were committed post > 1.3.1) > >> > not > >> > > > > >> >> mentioned in > >> > > > > >> >> > >> > 1.4.0 CHANGES.txt? > >> > > > > >> >> > >> > > >> > > > > >> >> > >> > Seems fine. Just asking. > >> > > > > >> >> > >> > > >> > > > > >> >> > >> > St.Ack > >> > > > > >> >> > >> > > >> > > > > >> >> > >> > > >> > > > > >> >> > >> > > >> > > > > >> >> > >> >> -- > >> > > > > >> >> > >> >> Best regards, > >> > > > > >> >> > >> >> Andrew > >> > > > > >> >> > >> >> > >> > > > > >> >> > >> >> Words like orphans lost among the crosstalk, > meaning > >> > torn > >> > > > > from > >> > > > > >> >> > truth's > >> > > > > >> >> > >> >> decrepit hands > >> > > > > >> >> > >> >> - A23, Crosstalk > >> > > > > >> >> > >> >> > >> > > > > >> >> > >> > >> > > > > >> >> > > > >> > > > > >> >> > > > >> > > > > >> >> > > > >> > > > > >> >> > > -- > >> > > > > >> >> > > Best regards, > >> > > > > >> >> > > Andrew > >> > > > > >> >> > > > >> > > > > >> >> > > Words like orphans lost among the crosstalk, meaning > torn > >> > > from > >> > > > > >> truth's > >> > > > > >> >> > > decrepit hands > >> > > > > >> >> > > - A23, Crosstalk > >> > > > > >> >> > > > >> > > > > >> >> > > >> > > > > >> >> > > >> > > > > >> >> > > >> > > > > >> >> > -- > >> > > > > >> >> > Best regards, > >> > > > > >> >> > Andrew > >> > > > > >> >> > > >> > > > > >> >> > Words like orphans lost among the crosstalk, meaning > torn > >> > from > >> > > > > truth's > >> > > > > >> >> > decrepit hands > >> > > > > >> >> > - A23, Crosstalk > >> > > > > >> >> > > >> > > > > >> >> > >> > > > > >> > > >> > > > > >> > > >> > > > > >> > > >> > > > > >> > -- > >> > > > > >> > Best regards, > >> > > > > >> > Andrew > >> > > > > >> > > >> > > > > >> > Words like orphans lost among the crosstalk, meaning torn > from > >> > > > truth's > >> > > > > >> > decrepit hands > >> > > > > >> > - A23, Crosstalk > >> > > > > >> > > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> -- > >> > > > > >> Best regards, > >> > > > > >> Andrew > >> > > > > >> > >> > > > > >> Words like orphans lost among the crosstalk, meaning torn > from > >> > > truth's > >> > > > > >> decrepit hands > >> > > > > >> - A23, Crosstalk > >> > > > > >> > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Best regards, > >> > > > Andrew > >> > > > > >> > > > Words like orphans lost among the crosstalk, meaning torn from > >> truth's > >> > > > decrepit hands > >> > > > - A23, Crosstalk > >> > > > > >> > > > >> > > >> > > > > -- > Sean > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
