Hoss, feels like a lot of files.. We already have all those .sha files for dependencies….
I lean towards just not worrying too much about the changelog and accept that at release time, a human paired with an LLM is going to make a great dependencies update artifact. Honestly, we kind of already are in that boat.. The VEX files that populate our Solr-site repo, as dependencies are updated, they all require updates as well. I guess that is why I lean towards option 1, tell Solrbot not to generate a changelog, knowing it’s not going to be very useful. Or maybe Option 1b, let it, and not worry too much about it. > On Sep 1, 2026, at 6:53 PM, Chris Hostetter <[email protected]> wrote: > > > > : 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 > <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/ <http://www.lucidworks.com> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
