> Yes, those are the rules I applied.
To clarify: Those are the rules I applied after going back and adding back
fixversions such that the set {1.3.1, ...} becomes {1.4.0, 1.3.1, ...} as
Sean suggested.
Now, 1.4.0 was dropped only if there is a fixversion 1.3.0 in the set. And,
1.5.0 was dropped wherever we have 1.4.0 in the set, and that is currently
everywhere because at this moment branch-1.4 == branch-1, but will begin to
diverge as soon as 1.4.0 is released.
On Thu, Nov 9, 2017 at 11:21 AM, Andrew Purtell <[email protected]> wrote:
> Yes, those are the rules I applied.
>
> While I was in there adjusting fixversions I noticed that generally we
> follow exactly that approach for numbering. I think we inherit it from
> Hadoop, because our old timers came from that community.
>
> Dave - Please consider submitting a patch for our online book for this, if
> the text doesn't already exist in there somewhere.
>
> On Thu, Nov 9, 2017 at 11:17 AM, Dave Latham <[email protected]> wrote:
>
>> +1 for making it as simple as possible to determine if a given fix is in a
>> given release purely from the release numbers, without having to consult
>> the dates of when branches were made or release candidates were built.
>>
>> I think the rules should be
>>
>> Fix version of X.Y.Z => fixed in all releases X.Y.Z' where Z' >= Z
>> Fix version of X.Y.0 => fixed in all releases X.Y'.* where Y' >= Y
>> Fix version of X.0.0 => fixed in all releases X'.*.* where X' >= X
>>
>> By this policy, fix version of 1.3.0 implies 1.4.0, but 1.3.2 does not
>> imply 1.4.0, as we could not tell purely from the numbers which release
>> came first.
>>
>> To track a fix then, I think that means that there should usually be a fix
>> version added for each branch that a commit was pushed to, with the
>> exception of master if there is a branch for the next major release that
>> has not happened yet.
>>
>> I think this is probably just repeating what Sean was saying, but it was
>> helpful for me to write out and perhaps helpful for others to think about.
>>
>> On Thu, Nov 9, 2017 at 10:37 AM, Andrew Purtell <[email protected]>
>> wrote:
>>
>> > Related, on HBASE-18996 Peter said:
>> >
>> > the fix version is not correct. It should include 1.5 too. Did you
>> remove
>> > that on purpose?
>> >
>> > and my response:
>> >
>> > Yes, I removed 1.5.0 for anything that is going out in 1.4.0. Fix
>> versions
>> > in HBase have historically meant the same thing as in Hadoop, which is
>> "in
>> > this release and any later". That said, I'm only touching fix versions
>> for
>> > branch-1. I won't presume to mess with fix version accounting for
>> branch-2.
>> > We have another RM tending to that.
>> > At this point branch-1 (1.5.0) == branch-1.4 (1.4.0) so having both in
>> > fixversions would be fine but redundant, and a future RM would have some
>> > work to do. As things stood, they were horribly inconsistent, with many
>> > 1.5.0 fixversions missing.
>> >
>> >
>> > On Thu, Nov 9, 2017 at 10:27 AM, Andrew Purtell <[email protected]>
>> > wrote:
>> >
>> > > You mean put back the 1.4.0 fixversion for anything released in
>> 1.3.1? I
>> > > can do that. I don't have a strong opinion either way. Let me make a
>> pass
>> > > now.
>> > >
>> > > Any other suggestions?
>> > >
>> > >
>> > > On Thu, Nov 9, 2017 at 6:15 AM, Sean Busbey <[email protected]>
>> wrote:
>> > >
>> > >> I'd like to try convincing you to just drop issues that were in
>> 1.3.0.
>> > >>
>> > >> I assume that 1.4 will become our new stable line. Suppose that I am
>> > >> running on our stable 1.2 release line. When considering an upgrade
>> to
>> > >> 1.4.z, which CHANGES files do I have to read to get a sense of what I
>> > >> have to look out for in changes?
>> > >>
>> > >> Presuming the 1.3.0 CHANGES files contains everything that changed
>> > >> since 1.2.0, I could just read the 1.3.0 CHANGES and then the CHANGE
>> > >> for the 1.4.z release I am aiming for (since it will have 1.4.0 -
>> > >> 1.4.z in it).
>> > >>
>> > >> If you use a later 1.3.z as the basis, then I have to find what the
>> > >> last 1.3.z that had its RC created before 1.4.0. (a later one will
>> > >> cover changes that are not included in 1.4.0 and might not be in any
>> > >> 1.4.z yet)
>> > >>
>> > >> On Thu, Nov 9, 2017 at 12:05 AM, Stack <[email protected]> wrote:
>> > >> > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <
>> [email protected]>
>> > >> wrote:
>> > >> >
>> > >> >> You may notice I'm dropping '1.4.0' from fix versions wherever we
>> > have
>> > >> >> something that went in to any 1.3.x. This is because I am basing
>> the
>> > >> >> CHANGES.txt changelog for 1.4.0 on the latest from branch-1.3, so
>> > >> anything
>> > >> >> that went in on branch-1.3 will be included in the changelog at
>> the
>> > >> correct
>> > >> >> point in history. Anything in the 1.4.0 section of the changelog
>> for
>> > >> >> branch-1.4 will be for changes in branch-1.4 not in branch-1.3.
>> > >> >>
>> > >> >>
>> > >> > If 1.4.0 goes out before 1.3.2, does that mean, there will be fixes
>> > that
>> > >> > are in 1.4.0 (because they were committed post 1.3.1) not
>> mentioned in
>> > >> > 1.4.0 CHANGES.txt?
>> > >> >
>> > >> > Seems fine. Just asking.
>> > >> >
>> > >> > St.Ack
>> > >> >
>> > >> >
>> > >> >
>> > >> >> --
>> > >> >> Best regards,
>> > >> >> Andrew
>> > >> >>
>> > >> >> Words like orphans lost among the crosstalk, meaning torn from
>> > truth's
>> > >> >> decrepit hands
>> > >> >> - A23, Crosstalk
>> > >> >>
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Best regards,
>> > > Andrew
>> > >
>> > > Words like orphans lost among the crosstalk, meaning torn from truth's
>> > > decrepit hands
>> > > - A23, Crosstalk
>> > >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Andrew
>> >
>> > Words like orphans lost among the crosstalk, meaning torn from truth's
>> > decrepit hands
>> > - A23, Crosstalk
>> >
>>
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
