1.5.0 needs to appear already since a) we need a place to target fixes that we're booting out of 1.4.0 and b) branch-1 and branch-1.4 have diverged so a fix in one does not necessarily mean a fix is in the other.
On Thu, Nov 9, 2017 at 11:50 PM, Yu Li <[email protected]> wrote: > It would be a pain for user to judge whether a patch for 1.3.1 is included > in 1.4.0 from the version number, they will have to get and compare the > release timeline of 1.3.1 and 1.4.0. So I'm a big fun of the already taken > action: "Now, 1.4.0 was dropped only if there is a fixversion 1.3.0 in the > set" > > bq. For example, don't mark 'fixed in 1.5' on the JIRA until 1.4.0 is out > I'm not that sure but it seems to me 1.5 shouldn't appear in the "Fix > version" options before 1.4.0 is out? > > Best Regards, > Yu > > On 10 November 2017 at 08:19, Jerry He <[email protected]> wrote: > >> 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 >> > > > >> > > >> > >> -- Sean
