: 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
