On Wed, Oct 19, 2011 at 9:25 AM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Hi, > > On Wed, Oct 19, 2011 at 1:06 PM, Nick Burch <nick.bu...@alfresco.com> wrote: >> Quick query - I notice that some people are updating CHANGES.txt when they >> close out issues. I had thought that part of the release process was going >> through the FIXED list in JIRA to build that up, so I hadn't been doing it. >> >> What's the view here, should we be doing it on most things, just major >> things, or holding off for the release manager to do it from a JIRA report? > > The most accurate and complete change history information should in > any case always be found in Jira and just referenced from CHANGES.txt, > so in my view there's no need to update CHANGES.txt for all or even > most changes. Most notably I'd rather not have us duplicate > information between Jira and CHANGES.txt. > > Instead the CHANGES.txt file is a good vehicle for pointing out > important changes or highlighting interesting new features that > otherwise might get lost in the noise.
I agree Jira is the "fallback" when you want to drill down and see all the details behind a change. But by design CHANGES will duplicate information from Jira, right? (ie, because it's a brief summary of each change). Or... are you saying CHANGES should not include "minor" issues? Only "big" ones? And users need to go to Jira to get a complete list? Ie this has changed from a discussion on "when should we add the entries to CHANGES" (on committing the change vs at release time) to a question of "what should CHANGES contain". Mike
