accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] CHANGES Documents
Date Thu, 20 Feb 2014 18:21:37 GMT
On Thu, Feb 20, 2014 at 1:10 PM, Josh Elser <josh.elser@gmail.com> wrote:

> On 2/20/14, 10:00 AM, Keith Turner wrote:
>
>> On Thu, Feb 20, 2014 at 1:10 AM, Sean Busbey<busbey+lists@cloudera.com
>> >wrote:
>>
>>  >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 would really like to see this type of information called out in release
>> notes.
>>
>
> Agreed
>
>
>
>  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
>> release.
>>
>>
> I'd prefer to not hold up 1.5.1 for something like this, and would rather
> just follow suite with 1.4. By this, you mean having all CHANGES from 1.4.X
> and 1.5.0 in addition to the 1.5.1 changes, correct? Is this acceptable to
> everyone? I know there were other suggestions made and don't want to
> prematurely squash discussion.
>

I was thinking taking the 1.5.0 changes file and adding the 1.5.1 stuff to
it.  If we did anything w/ 1.4, we would would only want to take 1.4.0
changes and add that after 1.5.0.  Not all changes in 1.4.[1.2.3.4] are in
1.5 series and any changes that are in both are hopefully marked properly
in jira and already in the 1.5.X list. Since the 1.4.0 changes were not
listed in 1.5.0, I am not neutral on adding that in 1.5.1.


>
> For 1.6.0, I would be happy to play around with some static-content
> generation tools (I like jekyll[1], personally, but I'll have to try out a
> few for our needs. We could even try to reuse the ASF CMS codebase) and see
> if we can get a markdown-generated document going that we can create a nice
> release-notes page from.
>
> [1] http://jekyllrb.com/
>

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