hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Fix version maintenance for 1.4.0
Date Thu, 09 Nov 2017 20:23:39 GMT
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 <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?
>
> 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
> >
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

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