hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: Release 1.4.0 update
Date Sat, 11 Nov 2017 17:53:46 GMT
I'll do a PE comparison between 1.4.0 and 1.3 and/or 1.2. Maybe YSCB too if I have time. Good
idea, thanks. 

> On Nov 11, 2017, at 5:05 AM, Yu Li <carp84@gmail.com> wrote:
> Great to know, really good progress!
> It seems we don't do performance comparison with current stable release
> when releasing the first RC of a new branch, but should we do to avoid
> issues like HBASE-14460 (write performance regression from 0.98 to 1.1)?
> This is a must-have for us to decide new version for product env here, and
> I wonder whether this applies for most users (please forgive my ignorance
> if there's any existing policy for this). Thanks.
> bq. Back when we first discussed branching for 1.4 Yu Li asked for this...
> Thanks for remembering this and keeping the promise boss (smile).
> Best Regards,
> Yu
>> On 11 November 2017 at 03:30, Andrew Purtell <apurtell@apache.org> wrote:
>> The march to 1.4.0 is progressing.
>> I've run the unit test suite on a C4 class AWS instance 25 times and there
>> are no failures. This is ongoing. I'm aiming for 100 runs.
>> Fix versions are now set up for constructing a reasonable change log.
>> With HBASE-19232 applied a build with release audits enabled will pass.
>> I backported error-prone support yesterday and will now look at checkstyle
>> and error-prone analyses for important issues.
>> I'll probably do HBASE-19238 before 1.4.0 goes out so that neat utility
>> will be available.
>> Back when we first discussed branching for 1.4 Yu Li asked for this:
>>> One naive question here: from the book
>>> <http://hbase.apache.org/book.html#hbase.versioning> we will add
>>> functionality (in a backwards-compatible manner) in minor versions, but
>> it
>>> seems we don't have any one-line description on the differences (what
>>> main functionalities have been added) between branch-1.1/1.2/1.3/1.4 so
>>> user could better decide which version to choose/upgrade. Should we
>>> add some explicit document on this? Or release note of the first release
>>> for each branch is enough? Thanks.
>> and I still agree to do it. I'll write it up while the RC is under
>> evaluation.
>> ITBLL and replication testing to be performed on a small cluster once we
>> have the RC binaries.
>> Anything else? (Within reason...)
>> --
>> Best regards,
>> Andrew
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>   - A23, Crosstalk

View raw message