Only two of those listed use-cases could be answered by the changelog. Most weren't *change* oriented but the changelog is about *changes*. This reinforces to me that we should do what I proposed -- DROP the solrbot driven changes. Don't burden the RM with deriving a list of all dependencies that *changed*. If someone *really* wants to know... I would advise them not to trust our changelog for such a thing anyway -- not unless we have an automated solution.
And you had non-changelog answers for the *change* ones: > “I am aware of this CVE in this dependency of Solr, did it get fixed” —> Consult our VEX entries for that dependency and the version of Solr concerned. > “I use a specific module of Solr, what does that drag along”. —> Maybe an SBOM for Solr itself? On Thu, Sep 10, 2026 at 7:45 AM Eric Pugh <[email protected]> wrote: > I lean towards the manual (AI assisted) cleanup approach. There are too > many people working across a long release cycle with differing opinions on > what is changelog worthy to get it to an automated process that drives a > lot of value. > > I am also wondering more and more if the changelog is the right way to > convey dependency changes? It really quickly becomes a big list of many > unknown libraries. I think we need to look at it more from “What do people > want to know” in order to understand best way to answer it. For example: > > “I use SolrJ, what do I need to do to upgrade to the next version”. —> > List of SolrJ required dependencies in the Ref Guide. > > “I use Solr slim bistro, I really care about specific changes”. —> Maybe > we should be using a SBOM for this use case? “This is what we actually > ship in Solr binary”. > > “I use a specific module of Solr, what does that drag along”. —> Maybe an > SBOM for Solr itself? > > “I am aware of this CVE in this dependency of Solr, did it get fixed” —> > Consult our VEX entries for that dependency and the version of Solr > concerned. > > > > > > On Sep 10, 2026, at 2:49 AM, Jan Høydahl <[email protected]> wrote: > > > > Thanks for bringing it to the list, we already started discussing this > topic on some solrbot PRs. > > > > Surprised the wizard still proposes a py script, as it would be > duplicating entries already filed by solrbot on each patch. > > And you are correct that, when so much time passes between releases, > there will be solrbot duplicates, or triple or quadruple entries for the > same dependency. > > > > A better process is needed, but may I suggest a manual (AI assisted) > cleanup for the upcoming release, where you prune duplicates and fix > nonsense titles like the below example. Like back when we had CHANGES.txt I > always fixed it up, removing duplicates or dead meat, rewriting some > entries etc. > > > > Then this thread may hopefully decide an improved process going forward. > > Good point though on the shipped vs non-shipped distinction, a test-only > or build-only dependency is obviously not that interesting for a changelog. > > > > Jan > > > > > 10. sep. 2026 kl. 04:10 skrev David Smiley <[email protected]>: > > > > > > Not only does that script generate a bunch of changelog yaml, but we > > > already have lots of existing ones. I wish to remove them: > > > https://github.com/apache/solr/pull/4895 < > https://github.com/apache/solr/pull/4895> > > > > > > On Wed, Sep 9, 2026 at 9:59 PM David Smiley <[email protected]> > wrote: > > > > > >> (I'm writing this in the context of being the release manager for > 9.11) > > >> > > >> It's unclear how I should handle changelogs for dependencies. If I > > >> blindly follow the release wizard like a robot, it runs: > > >> python3 -u dev-tools/scripts/addDepsToChanges.py --user solrbot > > >> --version 9.11.0 > > >> Which in turn uses "git log" to find all commits by "solrbot" and > converts > > >> that commit to a yaml entry. After lots of months, there are *many* > yaml > > >> files. Many look expected / boring. But then there are some > interesting > > >> entries such as the following: > > >> > > >> title: Update all non-major dependencies > > >>> type: dependency_update > > >>> authors: > > >>> - name: solrbot > > >>> links: > > >>> - name: PR#4597 > > >>> url: https://github.com/apache/solr/pull/4597 < > https://github.com/apache/solr/pull/4597> > > >>> > > >> > > >> I *love* that it was one PR for many dependencies instead of a > shotgun of > > >> commits! But it doesn't even say what it updated exactly; sigh. > Imaging > > >> searching git log message to find an update and not getting a hit > here; > > >> ouch! An earlier bulk dependency update at least had a detailed commit > > >> message. Now consider that there are other many other solrbot > individual > > >> updates... which begs the question: how is this to be mixed with > those? > > >> If I ignore this problem as RM, we have a mismash of partial > information. > > >> > > >> I propose dropping "solrbot" authored changelog entries entirely. Drop > > >> this step in the release wizard, drop that python script. The > changelog > > >> *does* have dependency updates that were interesting enough to be > done by > > >> (or on behalf of) a named human. > > >> > > >> I'm in favor of someday maybe adding a single changelog entry per > release > > >> with a compact list of dependencies that were updated, filtered to > those > > >> that we actually ship in a binary distribution. But IMO not a > priority. > > >> > > >> ~ David Smiley > > >> Apache Lucene/Solr Search Developer > > >> http://www.linkedin.com/in/davidwsmiley < > http://www.linkedin.com/in/davidwsmiley> > > >> > > > > > > --------------------------------------------------------------------- > > 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. >
