hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yu Li <car...@gmail.com>
Subject Re: Fix version maintenance for 1.4.0
Date Fri, 10 Nov 2017 13:51:53 GMT
I see, thanks for the clarification.

Best Regards,
Yu

On 10 November 2017 at 21:38, Sean Busbey <sean.busbey@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 <carp84@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 <jerryjch@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 <stack@duboce.net> wrote:
> >>
> >> > On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob <mdrob@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 <busbey@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message