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 >
