For clarity, tickets that aren't Closed or Resolved are (typically for
us) Duplicate, Invalid, Won't Fix, etc.
On 2/19/14, 6:18 PM, Sean Busbey wrote:
I think excluding tickets that aren't resolved is a good idea, but we'll
need to document that there may be commits that reference issues not
present in CHANGES because we are CtR.
On Feb 19, 2014 7:01 PM, "Josh Elser" <[email protected]> wrote:
One extra thing: in the CHANGES that I generated, I excluded any tickets
that didn't have a status of "Closed" or "Resolved".
Not sure what people think about that.
On 2/19/14, 1: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] http://accumulo.apache.org/releasing.html
