This tool does what is proposed here and looks promising: https://github.com/logchange/logchange?tab=readme-ov-file
It requires us to switch to CHANGES.md and it lacks a gradle plugin. But we could probably contribute some changes to fit our needs.. Jan Høydahl > 18. des. 2024 kl. 23:52 skrev Alessandro Benedetti <a.benede...@sease.io>: > > Hi guys, thanks to David for pointing me in the right direction. > > Noticed that more or less I already expressed the same concerns in the > past, so I was wondering if anyone has any new idea in these regards. > > Some new complaints from my side: > > 1) error prone (old complaint) > 2) prone to conflict (old complaint) > 3) couple a contribution to a specific release independently of the future > backporting or not (my current situation, I don't know if a feature is > going to 9.8, 9.9 or 10.x and I have to wait for that before I merge to > main) > > Following the Keep It Simple Stupid approach, can you remember me what's > wrong in just using the git log to produce a release note? Sure it won't be > as nice as the current version maybe, but from dev perspective I see this > as a huge win. > > Ideas? > > Cheers > >> On Fri, 17 May 2024, 23:32 Chris Hostetter, <hossman_luc...@fucit.org> >> wrote: >> >> >> : The thing about commit messages is they can't easily be cleaned up after >> : they are pushed... mistakes there are permanent. >> >> Exactly. >> >> In particular, a feature might be collaboratively developed & committed by >> Alice & Bob; but then before it's ever released Carl might find a bug with >> the new feature, which leads to a collaboration with Diane to tweak the >> API of the feature. ... which is uslaly best described as a *single* >> CHANGES entry that credits A+B+C+D (regardless of how many commits it >> takes) >> >> And even if we were all flawless humans that only ever made perfect >> commits -- not every commit is worthy of a mention in CHANGES (just >> like not every change is worthy of release note). >> >> : > > > 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 don't mean to call for the removal of github, but the PR model is what >> makes this particularly painful. If you avoid committing CHANGES.txt >> entries on your feature branches (or in the old days: in patch files >> attached to jira) there are less conflicts, and you can add the CHANGES >> entry after you (manually) run "git merge --squash" and before you run >> "git commit" >> >> : > > > 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 >> >> That sounds like a proposal I made on the lucene list 10-15 years ago. >> >> I still like it in theory. >> >> I'm not really a fan of the idea that the snippet files get deleted on >> release though... >> >> IIRC when i suggested this back in the day the focus of the discussion >> wasn't about simplifying individual commits/backports, allthough it was >> related. The pain point was some dispute as to wether bug fixes being >> released in (for example) 4.1.1, 4.0.1, and 3.9.7 should appear in the >> CHANGES entires for all 3 of those releases, or just 3.9.7 since it was >> oldest -- even though that might misslead people into thinking it was also >> "fixed" in 4.0.0 (and 4.1.0) and how to manage that in a way that made >> sense and didn't involve complicated merges between bug fix branches. >> >> My argument was that there should be a ./CHANGES/ directory where we kept >> small files each listing a single (logical) "Change Entry" and that the >> release process should (after prepending them all into CHANGES.txt) should >> *move* them into a subdirectory named after the release, and that sub >> direcory gets copied back to trunk (aka: main) >> >> The idea being that now it's very easy to tell -- both on release branch, >> and on main -- exactly what versions every change was made in, just by >> looking at the directory structure >> >> Mind you: this was all back in SVN when branches were a much more heavy >> weight operation then in GIT. I don't know that i feel strongly about the >> "copy back to main" bit, but I do think it would make more sense to move >> the snippet files into release specific directories then to just delete >> them outright. >> >> : > > > 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. >> >> Meh. If people want to look at "git log --oneline" they can. CHANGES >> should contain some value add of human curation. >> >> >> >> -Hoss >> http://www.lucidworks.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >>
