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 > > > > > >
