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 Thu, 20 Feb 2014 06:10:52 GMT
On Wed, Feb 19, 2014 at 10:33 PM, Christopher <ctubbsii@apache.org> 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 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]: http://s.apache.org/ih9

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