accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: [DISCUSS] CHANGES Documents
Date Thu, 20 Feb 2014 18:00:05 GMT
On Thu, Feb 20, 2014 at 1:10 AM, Sean Busbey <>wrote:

> On Wed, Feb 19, 2014 at 10:33 PM, Christopher <> wrote:
> >
> > value people are actually getting from this file. I strongly suspect
> > that, if anything, people just want to know the simple answers "What's
> > New?" and "Does this fix my bug yet?" questions, and I don't think
> > this file answers either of those questions well in any of the
> > previous releases. Nor do I think this format lends itself easily to
> > answering those questions. A per-release "Release Notes" section on
> > the website would probably be more useful for that purpose, with a
> > footnote reference to SCM/JIRA for the full list of changes. But, is
> > there another role the CHANGES file is expected to play which I'm
> > overlooking?
> >
> The main one I can think of is "Will this break my already working system
> in some other way?"
> So in addition to your two above major areas, I'd say a section on known
> backwards incompatible changes[1] would cover things.

I would really like to see this type of information called out in release

There have been a lot of good ideas mentioned.  What do we want to do for
1.5.1?  I would not be opposed to waiting a few days on the 1.5.1 release
if someone wants to create nice user friendly release notes.  Or for 1.5.1
we could just continue to do what was done for 1.4.X releases.   For 1.6.0
I think we should create a user friendly summary of whats important in the

> I agree that a section on the website would be more broadly useful than in
> the distribution (esp if we're authoring this rather than generating it via
> jira). I think it would be beneficial, however, to use Markdown in the CMS
> to author and then include that file directly in the distro as a snapshot
> for those offline. Authoring in the CMS would hopefully also encourage us
> to update the document incrementally rather than making the release manager
> handle it at the end.
> The more I reread this thread, the more I like the release notes described
> by Eric[2].
> -Sean
> [1]: To the public API, at a minimum. I think there are a few other things
> that practically speaking we should also call out, like changes to implicit
> configuration via defaults, the core iterators, or the Constraint
> interface.
> [2]:

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