Yeah, my understanding is that, in general, this is something folks see value in.
Whether it's a separate release artifact vs. "just" a file part of our distribution tgz, I don't have strong feelings about. It sounds like you're leaning towards the "release artifact" approach? Are there particular advantages of that plan you're aware of? (I'm not asking out of skepticism, but ignorance. I'm not that familiar with how these things are typically handled.) Best, Jason On Thu, Oct 15, 2026 at 6:30 AM Eric Pugh <[email protected]> wrote: > > > > On 2026-10-14 15:02 UTC Eric Pugh wrote: > > Hey all, > > > > Chatting with Piotr at C/C Glasgow about his SBOM contribution for Solr, > > and I wanted to take the temperature of the community on adding this > > artifact to our releases. What he is proposing in > > https://github.com/apache/solr/pull/4690 is to provide as part of our > > release a file that describes exactly what dependencies are in the binary > > archive. > > > > Adding SBOM's to releases would be a somewhat new thing for an Apache > > project. Apache Camel and PLC4X both ship SBOMs, and they have a lot of > > dependenices like us. Ivy and Ant as well as Log4j are other examples of > > project doing this. > > > > SBOM's might be the data structure that we could use to publish our > > dependency updates from release to release, instead of doing it via > > Changelog entries. We had a bit of disucssion in > > https://lists.apache.org/thread.html/1lbnk8ch6s92hlkh91bq2vzf738gppr0. It > > would also replace the current dependency mapping file in the solr-site > > used to track vex file ranges: > > https://github.com/apache/solr-site/blob/main/plugins/vex/solr-dependency-versions.json > > for any release that had it. > > > > Thoughts? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > It looks like the idea of SBOM's for Solr has actually been around for a few > years. We have a number of JIRAs that are open: > > https://issues.apache.org/jira/browse/SOLR-17328: Publish SBOMs for Solr > binary artifacts > https://issues.apache.org/jira/browse/SOLR-16796: Publish an SBOM for Solr > maven artifacts > > And a related: > > https://issues.apache.org/jira/browse/SOLR-17602: Maintain final JAR > dependencies in source control to track changes > https://issues.apache.org/jira/browse/SOLR-15929: Clean up NOTICE and LICENSE > files for Solr > > > Finding SOLR-18328 and SOLR-16796 shifts me more in the direction of "yes, > this is something we want to do as a community"... > > --------------------------------------------------------------------- > 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]
