We've been following a process where the Fix Version for any committed jira
is set to include the current version on all branches that the patch goes
to. Given this, I think we can generate a change-list / release notes quite
easily when a release is required.
Before a release, this can easily be looked up via jira, or the commit
history for that matter.

CHANGES.txt at the moment seems to cause conflicts (Pretty much all
cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's also
unnecessary noise, and the file often gets into an inconsistent state, if a
batch is back-ported to a branch after the initial commit to master
(CHANGES.txt on master needs to be updated to commit the patch to an older
branch)

I think we can do without this file at this point. Any reasons to keep it?

Thanks,
Sid

Reply via email to