Managing CHANGES.txt in each PR/change we do is a pain. It's so merge-conflict prone. I don't mean to call for the removal of CHANGES.txt (although I've wished for this off-and-on), but want to solicit inputs on what can be done to make this easier.
I could be mistaken but maybe it was Calvin Cowie that recommended a scheme something like the following: each change/PR merely adds its own txt file to a new CHANGES directory instead of adding to CHANGES.txt. Then it will be aggregated / concatenated to CHANGES.txt at a release boundary by the RM using a script. The per-change file then goes away. The category (e.g. New Feature vs Bug Fix) would need to be encoded somewhere, like maybe in the file name. Even the JIRA number could be part of the file name and not its content. No ad-hoc newline use either; just write the message and the script will line-wrap it. This is probably the simplest and least disruptive change. I'm kind of envious of small projects that can simply rely on GitHub's release notes generator [1]. Yeah it's just the first-line commit message, which emphasizes brevity over clarity. [1] https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
