hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Latham <lat...@davelink.net>
Subject Re: Fix version maintenance for 1.4.0
Date Thu, 09 Nov 2017 19:23:44 GMT
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 <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
>>
>
>

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