+1 to "1)". I'd much prefer a per-release aggregated changelog entry, or just don't bother. At least for most dependencies; some deserve a changelog.
On Tue, Sep 1, 2026 at 5:17 PM Jan Høydahl <[email protected]> wrote: > Thanks for raising the topic, > > Some history. While we still had CHANGES.txt, it was up to the RM to add > changelog entries for dependency updates. We had a py script that would do > changelog forensics, de-duplication and spit out a bullet list of what deps > were upgraded since the previous git tag. > > With the introduction of logchange, we changed so that changelog moved > together with each renovate PR, as today, hoping that everything would be > corrrect automatically and no extra RM job for these. But that kind of > re-introduced duplicates (same lib upgraded 2-3 times between releases) and > now with grouping it got even more complicated. Besides, dependencies are > not all alike. Some like Lucene and Jetty are much more prominent than > others and sometimes deserve a more careful changelog than the one-liner. > > So I'm warming up to the thought of return to letting this be an RM task, > backed by a script, perhaps with some LLM copywriting. > > Jan > > > 1. sep. 2026 kl. 21:27 skrev Eric Pugh <[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 … > > > > > > It seems like we have a few options: > > > > 1) Tell Solrbot NOT to generate the changelog entry at all, since > "title: Update all non-major dependencies” isn’t useful. > > > > 2) Require who ever merges these to tweak the changelog to list out all > the items that are changed as part of the change. Though that might be a > very long list? > > > > 3) Maybe adopt documenting the dependency changes as part of the release > process? “These are the dependencies that changed between the previous > release the current one”? > > > > > > For my part, I want to see the effort for whoever is merging these go > down, so we don’t get back into a situation where we are way out of date on > dependencies. And since Solrbot fires off 12 times a year, it means we > are only ~29 days from the next batch of Solrbot PR’s! > > > > Eric > > > > > > > > > > > > > > > >> On Sep 1, 2026, at 8:47 AM, Eric Pugh <[email protected]> > wrote: > >> > >> It’s the first of the month, and we have 20 PR’s opened by Solrbot! > https://github.com/apache/solr/pulls/solrbot > >> > >> We have six targeting branch_9x, and the rest are targeting main. > Looks like the “Milestone” label being set to 10x is being applied, so at > least the back porting should happen via David’s magic bak porting process. > >> > >> > >> I think it’s kind of good news / bad news thing that it appears that > the grouping has cut down on the number of PRs, like this one > https://github.com/apache/solr/pull/4842 and > https://github.com/apache/solr/pull/4845…. I can’t imagine what it was > like before we had grouping. > >> > >> It looks like however we don’t have grouping on the branch_9x PR’s, > with six different PR’s. > >> > >> I don’t know if 20 is going to be the average number per month, but I > hope not! > >> > >> It would be great if other folks look at the PR’s and approved them. > >> > >> > > > > 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. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
