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 19:21:42 GMT
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

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