On Thu, Feb 20, 2014 at 1:21 PM, Keith Turner <[email protected]> wrote:
> > > > On Thu, Feb 20, 2014 at 1:10 PM, Josh Elser <[email protected]> wrote: > >> On 2/20/14, 10:00 AM, Keith Turner wrote: >> >>> On Thu, Feb 20, 2014 at 1:10 AM, Sean Busbey<[email protected] >>> >wrote: >>> >>> >On Wed, Feb 19, 2014 at 10:33 PM, Christopher<[email protected]> >>>> 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. > s/not neutral/not not neutral/ > > >> >> 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/ >> > >
