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 > >
