[
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]
{quote}
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 format.
{quote}
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):
{quote}
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._
{quote}
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
(v6.3.4#6332)
