You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A release will have tarballs for source and binary distribution that must be signed by RM. I hope that we could pilot ASFs code signing infrastructure to auto sign distributons, should probably check with INFRA what that takes.
Docker image could be released, after passing vote through e.g. a manually triggered Github workflow run? It need not be an "official" image, but can live in apache/solr-mcp
@adityamparikh and I are chatting, and thinking about how to get to a 1.0 out the door. I'm proposing that we use the ATR for running the release communication/voting process, but we still manually build the artifact locally and sign it, and we of course have to manually add the artifacts to Subversion.
I don't want to wait for all the magic Github automation to happen, partly because I'm not confident of my own ability to navigate that process, and I want 1.0 to get out.
The release process has gone fairly roughly... First time around we had some existing security concerns, and the second time we are missing the -src files in the ATR package. Interesting that ATR didn't flag this!
Activity
adityamparikh commentedon Nov 4, 2025
When a pull request is merged, GitHub actions should publish a docker image to Docker MCP Hub https://hub.docker.com/mcp as well as to the MCP Registry https://github.com/modelcontextprotocol/registry/blob/main/docs/guides/publishing/github-actions.md?
Question on what authentication mechanism should be used https://github.com/modelcontextprotocol/registry/blob/main/docs/guides/publishing/github-actions.md#authentication-methods
janhoy commentedon Nov 4, 2025
Any releaes must of course go through the ASF release process with a 72h voting period before we can release to Docker hub or MCP registry.
But we may do nightly builds to our area at https://nightlies.apache.org/solr/ and to our preview docker coordinates at https://hub.docker.com/r/apache/solr-nightly. If such build and publication happen on each merge or nightly is both ok I guess.
A release will have tarballs for source and binary distribution that must be signed by RM. I hope that we could pilot ASFs code signing infrastructure to auto sign distributons, should probably check with INFRA what that takes.
Docker image could be released, after passing vote through e.g. a manually triggered Github workflow run? It need not be an "official" image, but can live in apache/solr-mcp
epugh commentedon Jan 6, 2026
@adityamparikh and I are chatting, and thinking about how to get to a 1.0 out the door. I'm proposing that we use the ATR for running the release communication/voting process, but we still manually build the artifact locally and sign it, and we of course have to manually add the artifacts to Subversion.
I don't want to wait for all the magic Github automation to happen, partly because I'm not confident of my own ability to navigate that process, and I want 1.0 to get out.
epugh commentedon Jan 6, 2026
Tasks that we've identified that need to happen:
epugh commentedon Jun 3, 2026
The release process has gone fairly roughly... First time around we had some existing security concerns, and the second time we are missing the -src files in the ATR package. Interesting that ATR didn't flag this!
epugh commentedon Jun 4, 2026
I have pinged the ATR folks on slack: https://the-asf.slack.com/archives/C049WADAAQG/p1780575489259509
refactor: replace mutable Date with Instant in DTO records (apache#113)