I feel the same. It's error-prone, easy to forget and even easier to end up with conflicts.
Sure, once there, it's useful and I end up reading it from time to time, to quickly refresh on the latest contributions I (or my team) did (but the git log is more than enough for that). In the end, what's in the Changes? - Type of Contribution ( New Features, Improvements, Optimizations, Bug Fixes, Dependency Upgrades, Other Changes) - earlier release the change is appearing - A headline containing JIRA reference, a short description, Authors I think all of this information can be in the commit message, author and pull request metadata (release version and type of contribution). I definitely like the idea of having the release note automatically generated from the info above (potentially in a similar manner to the link shared by David). I admit I've not looked into technical solutions and I am not sure I can help pragmatically, but I'll do my best if go this renovation route. Cheers -------------------------- *Alessandro Benedetti* Director @ Sease Ltd. *Apache Lucene/Solr Committer* *Apache Solr PMC Member* e-mail: a.benede...@sease.io *Sease* - Information Retrieval Applied Consulting | Training | Open Source Website: Sease.io <http://sease.io/> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter <https://twitter.com/seaseltd> | Youtube <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github <https://github.com/seaseltd> On Thu, 16 May 2024 at 21:26, Eric Pugh <ep...@opensourceconnections.com> wrote: > 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. > >
