accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Newton <>
Subject Re: [DISCUSS] CHANGES Documents
Date Wed, 19 Feb 2014 21:53:51 GMT
I think generated CHANGES files are a disservice to the reader.

A short list of the major differences from the last release should be given.

For a bug release, a short list of the critical bugs should be given after
the .0 release.

So, 1.4.1 would list the 1.4.0 features, and the critical bugs that caused
the 1.4.1 release to be made.
1.4.2 would list 1.4.0 features, 1.4.1 and 1.4.2 critical bug fixes.

Basically, I want to quickly understand if I should upgrade (or not).

If people want the full list, they can get it from JIRA.

I would also be fine with a CHANGES file with a URL reference to JIRA.

I personally would not down-vote a release because it has an accurate
CHANGES file, but not the content I think it should have.


On Wed, Feb 19, 2014 at 4:30 PM, Josh Elser <> wrote:

> The CHANGES document that is included in an Accumulo release contains some
> set of changes from a previous release which presently contain the
> following information:
> 1) Issue Type (Task, Bug, Feature, etc)
> 2) Issue Number (ACCUMULO-1234)
> 3) Issue Subject
> There have been various preferences expressed, primarily over IRC, on
> which changes should be contained and how they should be formatted. The
> largest consensus, and what I believe we should do, is as follows:
> Entries in a CHANGES file should contain issues, delimited by minor
> version within the major version[1], grouped by issue type. The minor
> version changes sorted be sorted in reverse order (e.g. 1.5.2, 1.5.1, then
> 1.5.0). Changes from the previous major version (e.g. 1.4.x) would *not* be
> included in this CHANGES file.
> Opinions? The results of this discussion will be documented on the
> release-making page[2] of the website for future reference.
> - Josh
> [1] Major and minor version here is referred to as Y and Z of version
> strings of the form: X.Y.Z (not as prescribed by semver, proper)
> [2]

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