You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Andrew Purtell <ap...@apache.org> on 2017/11/09 00:31:00 UTC
Fix version maintenance for 1.4.0
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.
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: Fix version maintenance for 1.4.0
Posted by Andrew Purtell <ap...@apache.org>.
I only dropped 1.4.0 from fix versions if it went out in a released 1.3, so
if there was a fix version of '1.3.1' or '1.3.0' then it was dropped,
otherwise it was not.
On Wed, Nov 8, 2017 at 10:05 PM, Stack <st...@duboce.net> wrote:
> On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <ap...@apache.org>
> 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
Re: Fix version maintenance for 1.4.0
Posted by Andrew Purtell <ap...@apache.org>.
Up to the branch2 RM I'd say. Can we have a separate discussion for that? I
think this one is good.
On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <md...@apache.org> 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?
>
> On Thu, Nov 9, 2017 at 1:42 PM, Andrew Purtell <ap...@apache.org>
> 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 <bu...@apache.org> 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 <la...@davelink.net>
> 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 <apurtell@apache.org
> >
> > > 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 <
> apurtell@apache.org>
> > > >> 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 <latham@davelink.net
> >
> > > >> 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 <
> > apurtell@apache.org
> > > >
> > > >> >> 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 <
> > > apurtell@apache.org>
> > > >> >> > 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 <
> busbey@apache.org
> > >
> > > >> >> 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 <st...@duboce.net>
> > > wrote:
> > > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> > > >> >> apurtell@apache.org>
> > > >> >> > >> 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
> >
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: Fix version maintenance for 1.4.0
Posted by Andrew Purtell <ap...@apache.org>.
I can confirm there are a few things committed to branch-1 not in
branch-1.4 now. Fix versions are set accordingly (1.5.0 is in the set,
1.4.0 is not)
On Fri, Nov 10, 2017 at 5:38 AM, Sean Busbey <se...@gmail.com> wrote:
> 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 <ca...@gmail.com> 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 <je...@gmail.com> 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 <st...@duboce.net> wrote:
> >>
> >> > On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <md...@apache.org> 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 <apurtell@apache.org
> >
> >> > > 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 <bu...@apache.org>
> >> > 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 <
> latham@davelink.net>
> >> > > 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 <
> >> > apurtell@apache.org
> >> > > >
> >> > > > > 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 <
> >> > > apurtell@apache.org>
> >> > > > > >> 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 <
> >> > latham@davelink.net
> >> > > >
> >> > > > > >> 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 <
> >> > > > apurtell@apache.org
> >> > > > > >
> >> > > > > >> >> 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 <
> >> > > > > apurtell@apache.org>
> >> > > > > >> >> > 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 <
> >> > > busbey@apache.org
> >> > > > >
> >> > > > > >> >> 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 <
> >> stack@duboce.net>
> >> > > > > wrote:
> >> > > > > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> >> > > > > >> >> apurtell@apache.org>
> >> > > > > >> >> > >> 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
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: Fix version maintenance for 1.4.0
Posted by Yu Li <ca...@gmail.com>.
I see, thanks for the clarification.
Best Regards,
Yu
On 10 November 2017 at 21:38, Sean Busbey <se...@gmail.com> wrote:
> 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 <ca...@gmail.com> 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 <je...@gmail.com> 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 <st...@duboce.net> wrote:
> >>
> >> > On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <md...@apache.org> 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 <apurtell@apache.org
> >
> >> > > 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 <bu...@apache.org>
> >> > 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 <
> latham@davelink.net>
> >> > > 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 <
> >> > apurtell@apache.org
> >> > > >
> >> > > > > 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 <
> >> > > apurtell@apache.org>
> >> > > > > >> 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 <
> >> > latham@davelink.net
> >> > > >
> >> > > > > >> 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 <
> >> > > > apurtell@apache.org
> >> > > > > >
> >> > > > > >> >> 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 <
> >> > > > > apurtell@apache.org>
> >> > > > > >> >> > 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 <
> >> > > busbey@apache.org
> >> > > > >
> >> > > > > >> >> 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 <
> >> stack@duboce.net>
> >> > > > > wrote:
> >> > > > > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> >> > > > > >> >> apurtell@apache.org>
> >> > > > > >> >> > >> 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
>
Re: Fix version maintenance for 1.4.0
Posted by Sean Busbey <se...@gmail.com>.
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 <ca...@gmail.com> 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 <je...@gmail.com> 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 <st...@duboce.net> wrote:
>>
>> > On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <md...@apache.org> 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 <ap...@apache.org>
>> > > 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 <bu...@apache.org>
>> > 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 <la...@davelink.net>
>> > > 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 <
>> > apurtell@apache.org
>> > > >
>> > > > > 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 <
>> > > apurtell@apache.org>
>> > > > > >> 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 <
>> > latham@davelink.net
>> > > >
>> > > > > >> 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 <
>> > > > apurtell@apache.org
>> > > > > >
>> > > > > >> >> 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 <
>> > > > > apurtell@apache.org>
>> > > > > >> >> > 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 <
>> > > busbey@apache.org
>> > > > >
>> > > > > >> >> 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 <
>> stack@duboce.net>
>> > > > > wrote:
>> > > > > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
>> > > > > >> >> apurtell@apache.org>
>> > > > > >> >> > >> 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
Re: Fix version maintenance for 1.4.0
Posted by Yu Li <ca...@gmail.com>.
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 <je...@gmail.com> 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 <st...@duboce.net> wrote:
>
> > On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <md...@apache.org> 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 <ap...@apache.org>
> > > 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 <bu...@apache.org>
> > 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 <la...@davelink.net>
> > > 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 <
> > apurtell@apache.org
> > > >
> > > > > 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 <
> > > apurtell@apache.org>
> > > > > >> 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 <
> > latham@davelink.net
> > > >
> > > > > >> 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 <
> > > > apurtell@apache.org
> > > > > >
> > > > > >> >> 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 <
> > > > > apurtell@apache.org>
> > > > > >> >> > 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 <
> > > busbey@apache.org
> > > > >
> > > > > >> >> 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 <
> stack@duboce.net>
> > > > > wrote:
> > > > > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> > > > > >> >> apurtell@apache.org>
> > > > > >> >> > >> 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
> > > >
> > >
> >
>
Re: Fix version maintenance for 1.4.0
Posted by Jerry He <je...@gmail.com>.
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 <st...@duboce.net> wrote:
> On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <md...@apache.org> 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 <ap...@apache.org>
> > 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 <bu...@apache.org>
> 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 <la...@davelink.net>
> > 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 <
> apurtell@apache.org
> > >
> > > > 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 <
> > apurtell@apache.org>
> > > > >> 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 <
> latham@davelink.net
> > >
> > > > >> 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 <
> > > apurtell@apache.org
> > > > >
> > > > >> >> 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 <
> > > > apurtell@apache.org>
> > > > >> >> > 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 <
> > busbey@apache.org
> > > >
> > > > >> >> 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 <st...@duboce.net>
> > > > wrote:
> > > > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> > > > >> >> apurtell@apache.org>
> > > > >> >> > >> 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
> > >
> >
>
Re: Fix version maintenance for 1.4.0
Posted by Stack <st...@duboce.net>.
On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <md...@apache.org> 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 <ap...@apache.org>
> 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 <bu...@apache.org> 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 <la...@davelink.net>
> 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 <apurtell@apache.org
> >
> > > 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 <
> apurtell@apache.org>
> > > >> 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 <latham@davelink.net
> >
> > > >> 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 <
> > apurtell@apache.org
> > > >
> > > >> >> 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 <
> > > apurtell@apache.org>
> > > >> >> > 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 <
> busbey@apache.org
> > >
> > > >> >> 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 <st...@duboce.net>
> > > wrote:
> > > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> > > >> >> apurtell@apache.org>
> > > >> >> > >> 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
> >
>
Re: Fix version maintenance for 1.4.0
Posted by Mike Drob <md...@apache.org>.
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 <ap...@apache.org> 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 <bu...@apache.org> 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 <la...@davelink.net> 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 <ap...@apache.org>
> > 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 <ap...@apache.org>
> > >> 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 <la...@davelink.net>
> > >> 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 <
> apurtell@apache.org
> > >
> > >> >> 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 <
> > apurtell@apache.org>
> > >> >> > 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 <busbey@apache.org
> >
> > >> >> 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 <st...@duboce.net>
> > wrote:
> > >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> > >> >> apurtell@apache.org>
> > >> >> > >> 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
>
Re: Fix version maintenance for 1.4.0
Posted by Andrew Purtell <ap...@apache.org>.
> 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 <bu...@apache.org> 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 <la...@davelink.net> 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 <ap...@apache.org>
> 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 <ap...@apache.org>
> >> 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 <la...@davelink.net>
> >> 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 <apurtell@apache.org
> >
> >> >> 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 <
> apurtell@apache.org>
> >> >> > 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 <bu...@apache.org>
> >> >> 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 <st...@duboce.net>
> wrote:
> >> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> >> >> apurtell@apache.org>
> >> >> > >> 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
Re: Fix version maintenance for 1.4.0
Posted by Sean Busbey <bu...@apache.org>.
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 <la...@davelink.net> 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 <ap...@apache.org> 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 <ap...@apache.org>
>> 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 <la...@davelink.net>
>> 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 <ap...@apache.org>
>> >> 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 <ap...@apache.org>
>> >> > 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 <bu...@apache.org>
>> >> 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 <st...@duboce.net> wrote:
>> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
>> >> apurtell@apache.org>
>> >> > >> 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
>>
Re: Fix version maintenance for 1.4.0
Posted by Dave Latham <la...@davelink.net>.
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 <ap...@apache.org> 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 <ap...@apache.org>
> 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 <la...@davelink.net>
> 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 <ap...@apache.org>
> >> 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 <ap...@apache.org>
> >> > 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 <bu...@apache.org>
> >> 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 <st...@duboce.net> wrote:
> >> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
> >> apurtell@apache.org>
> >> > >> 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
>
Re: Fix version maintenance for 1.4.0
Posted by Andrew Purtell <ap...@apache.org>.
> 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 <ap...@apache.org> 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 <la...@davelink.net> 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 <ap...@apache.org>
>> 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 <ap...@apache.org>
>> > 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 <bu...@apache.org>
>> 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 <st...@duboce.net> wrote:
>> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
>> apurtell@apache.org>
>> > >> 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
Re: Fix version maintenance for 1.4.0
Posted by Andrew Purtell <ap...@apache.org>.
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 <la...@davelink.net> 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 <ap...@apache.org>
> 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 <ap...@apache.org>
> > 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 <bu...@apache.org> 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 <st...@duboce.net> wrote:
> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <apurtell@apache.org
> >
> > >> 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
Re: Fix version maintenance for 1.4.0
Posted by Dave Latham <la...@davelink.net>.
Or, in other words, an issue should have a fix version marked for:
(a) first major version it's in
(b) first minor version it's in of any major version before (a)
(c) first patch version it's in of any minor version before (b)
On Thu, Nov 9, 2017 at 11:17 AM, Dave Latham <la...@davelink.net> 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 <ap...@apache.org>
> 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 <ap...@apache.org>
>> 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 <bu...@apache.org> 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 <st...@duboce.net> wrote:
>> >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <ap...@apache.org>
>> >> 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
>>
>
>
Re: Fix version maintenance for 1.4.0
Posted by Dave Latham <la...@davelink.net>.
+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 <ap...@apache.org> 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 <ap...@apache.org>
> 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 <bu...@apache.org> 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 <st...@duboce.net> wrote:
> >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <ap...@apache.org>
> >> 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
>
Re: Fix version maintenance for 1.4.0
Posted by Andrew Purtell <ap...@apache.org>.
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 <ap...@apache.org> 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 <bu...@apache.org> 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 <st...@duboce.net> wrote:
>> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <ap...@apache.org>
>> 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
Re: Fix version maintenance for 1.4.0
Posted by Andrew Purtell <ap...@apache.org>.
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 <bu...@apache.org> 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 <st...@duboce.net> wrote:
> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <ap...@apache.org>
> 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
Re: Fix version maintenance for 1.4.0
Posted by Sean Busbey <bu...@apache.org>.
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 <st...@duboce.net> wrote:
> On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <ap...@apache.org> 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
>>
Re: Fix version maintenance for 1.4.0
Posted by Stack <st...@duboce.net>.
On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <ap...@apache.org> 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
>