Up to the branch2 RM I'd say. Can we have a separate discussion for that? I think this one is good.
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? > > 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 > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
