I *do* find our current situation the worst of all possible options!
> On May 16, 2024, at 2:51 PM, David Smiley <dsmi...@apache.org> wrote: > > 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 > _______________________ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
