Hoss, The strategy of your proposal Hoss has crossed my mind as well. And if we are to keep automation, and keep the dep-upgrades section, this is I think one way forward. Currenlty the file name and title is pulled from the PR title, but for this new approach to work it must be pulled from the diff of libs.versions.toml I think.
Happy to hear other thoughts too. Jan > 2. sep. 2026 kl. 00:53 skrev Chris Hostetter <[email protected]>: > > > > : Okay, so how do we want to handle changelog entries for these from > : Solrbot? I want to draw attention to this conversation: > : https://github.com/apache/solr/pull/4842#pullrequestreview-5077496282 … > > Strawman proposal from someone who doesn't really know how solrbot > works... > > 1) Change it to stop putting the PR# and and version details in the > changelog/unreleased/ file *name* > > 2) It should just create file names like > "dep-update__google-errorprone.yaml" (that match the version key in > libs.versions.toml) > > 3) if a file with the same name already exists in changelog/unreleased/ , > it should just overwrite it completely. > > 4) if it updates 50 deps in a single PR, there should be 50 files created > in changelog/unreleased/ > > 5) humans doing manual dependency updates should follow the same practice > > > ...in theory, this leaves us with a situation where automated changelog > generation "just works" in terms of ensuring that we get a clean > "Dependency Upgrades" section that lists every dependency that was > upgraded since the last release -- but each dependency is listed no more > then once, listing the "latest" version it was upgraded to. > > > If we don't feel like *every* dependency is worthy of having it's upgrad > mentioned in the changelog, then there should be some way to annotate the > "important" dependencies (so both humans & solrbot can tell which ones are > worth documenting) and precommit should fail if a file in > changelog/unreleased/ exists named after a non-important dependency. > > > is that viable ? > > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
