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 >
