accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey+li...@cloudera.com>
Subject Re: [DISCUSS] CHANGES Documents
Date Wed, 19 Feb 2014 21:58:55 GMT
I'd prefer it if the CHANGES document included all changes, as they do in
Avro and Jackson[1]. For those who just get a distribution dropped on them,
it provides a very useful short way of tracking lots of info. Not everyone
can get to the source repo readily.

In this case the CHANGES file also then serves as an easy way of tracking
which minor versions of a previous major version are included in the
current major version.

This is especially true if users are cut off from the Internet and are
looking to upgrade from an older version.

Marginally related: I'd really like us to add a call out section for
backwards incompatible changes. (including from X.Y to X.Y+1)

[1]: http://svn.codehaus.org/jackson/tags/1.8/1.8.9/release-notes/VERSION
https://github.com/apache/avro/blob/trunk/CHANGES.txt

-Sean

On Wed, Feb 19, 2014 at 3:49 PM, Mike Drob <madrob@cloudera.com> wrote:

> I'd be happy with the solution described.
>
>
> I saw a project _somewhere_ using a way more detailed release notes style,
> of the format:
>
> [issue key] [priority] [issue type] reported by [reporter], resolved by
> [assignee]
> [summary]
>
> But that might be too verbose and I can't find it again anyway.
>
> Mike
>
>
> On Wed, Feb 19, 2014 at 4:30 PM, Josh Elser <josh.elser@gmail.com> 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
> >
>

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