CHANGES.txt is always a pain. *sigh* It seems that relying on human efforts to maintain the CHANGES.txt is error-prone and not sustainable. It is always a pain to fix them.
I think aw has some scripts for option 2. I would like to propose option 3 which might be more robust: (1) do a git log on the branch to figure out the jiras that are committed to the branch. and (2) generate CHANGES.txt by going through these jiras. That might eliminate the fix-version issue. I can volunteer some effort to help on this. ~Haohui On Sat, Sep 12, 2015 at 11:03 AM, Steve Loughran <ste...@hortonworks.com> wrote: > > I've just been trying to get CHANGES.TXT between branch-2 and trunk more in > sync, so that cherry picking patches from branch-2 up to trunk is more > reliable. > > Once you look closely , you see it is a mess, specifically: > > trunk/CHANGES.TXT declares things as in trunk only yet which are in branch-2 > and/or actual releases > > > What to do? > > 1. audit trunk/CHANGES.TXT against branch-2/CHANGES.TXT; anything in > branch-2's (i.e. to come in 2.8) is placed into trunk at that location; the > "new in trunk" runk's version removed > > 2. go to JIRA-generated change logs. Though for that to be reliable, those > fix-version fields have to be 100% accurate too. > >
