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
