hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Dimiduk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15881) Allow BZIP2 compression
Date Fri, 03 Jun 2016 18:16:59 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314524#comment-15314524

Nick Dimiduk commented on HBASE-15881:

bq. Is this not more like a new option (BZIP2) for an existing feature (compression)?

"New Feature" or "Improvement" is splitting hairs, it's not a bug fix, it's net new functionality.

[The Book|http://hbase.apache.org/book.html#hbase.versioning.post10]
Given a version number MAJOR.MINOR.PATCH, increment the:
 - MAJOR version when you make incompatible API changes,
 - MINOR version when you add functionality in a backwards-compatible manner, and
 - PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH

By the definitions above, this is clearly a MINOR change, not a PATCH change. However, under
"Summary" in the same sections, we note (emphasis my own):

A patch upgrade is a drop-in replacement. Any change that is not Java binary compatible would
not be allowed. _Downgrading versions within patch releases may not be compatible._

This implies we are could be allowed to ship such a not-bug-fix.

The patch itself looks harmless for a patch release. I'm more concerned about adhering to
our own guidelines.

> Allow BZIP2 compression
> -----------------------
>                 Key: HBASE-15881
>                 URL: https://issues.apache.org/jira/browse/HBASE-15881
>             Project: HBase
>          Issue Type: New Feature
>          Components: HFile
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 2.0.0, 1.0.4, 1.2.2, 0.98.20, 1.1.6, 1.3.1
>         Attachments: 15881-0.98.txt
> BZIP2 is a very efficient compressor in terms of compression rate.
> Compression speed is very slow, de-compression is equivalent or faster than GZIP.

This message was sent by Atlassian JIRA

View raw message