I think there might be a requirement for a self-contained src tarball that is self contained including build scripts, LICENSE, NOTICE files etc in order to download, understand what it does, build the tool etc. So yes I think we need a re-spin.
Why don't you embrace an RC model also for MCP, i.e. Release 1.0.0 RC1, RC2 etc? Does not ATR support that? As I said, I think it would be beneficial with instructions to devs on how to test the release artifacts duringa VOTE, more than just checking SHA's. It could be a step by step instruction, or it could be a smoke-test script. I prefer the latter. Wrt binary release, that is not a requirement of the ASF, it's for convenience only. Right now the only binary is the fat jar file. While it may be legal, I'd prefer it to be a tgz file with a LICENSE, NOTICE, README inside as well as the jar file. At a minimum. I don't think there's a need for start scripts here, at least not for the stdio mode. For the http server mode the binary distro could benefit from something more perhaps, dunno. Guess most folks witll use the docker image to host the http version. Speaking of Docker: Do we want to vote on the Dockerfile source as well, and include instructions on how to build Docker image from src tarball and test it? Final question: This code donation was developed outside ASF and brought in as a complete code grant. But we never filed an IP-clearance form to the incubator, did we? https://incubator.apache.org/ip-clearance/ I know about this form thorugh research for solr-orbit, but I did not know about it earlier when MCP codebase was brought in. Should we fill and file the form before the first release? Jan > 4. juni 2026 kl. 14:13 skrev Eric Pugh <[email protected]>: > > Regarding the lack of source files... I suspect that means this is NOT a > valid release package. > > This is my first time ever trying to be "Release Manager" for anything at > Apache, and I think I was leaning to much into the Apache Trusted Release > tool to make up for my lack of knowledge in this space. ATR validates your > release package in various ways. > > I just logged in (https://release-test.apache.org/checks/solr-mcp/1.0.0) and > it does label the file solr-mcp-1.0.0-sources.jar as a "src". > https://release-test.apache.org/report/solr-mcp/1.0.0/solr-mcp-1.0.0-sources.jar > says: "solr-mcp-1.0.0-sources.jar: Path structure and naming conventions > conform to policy". > > I then downloaded it, and realized that I think what you are suggesting is > that what we mean by src.tgz is a bundled up version of all the code that was > used to build the artifacts. In this case, it should be > https://github.com/apache/solr-mcp/tree/branch_1_0_0 ? > > I can ping the ATR folks about if there is a weakness in the tool that should > have flagged this as standard ASF policy! > > Do you think this means we need to redo this release process. And thoughts > on what that means? Last time I deleted the 1.0.0 release in ATR, and then > started over, which I could do on this as well. > > I am trackign this feedback in > https://github.com/apache/solr-mcp/issues/15#issuecomment-4613210696 as > clearly we need to harden the release process. > > Eric > > > > > On 2026/06/03 21:28:47 Aditya Parikh wrote: >> Regarding skills vs MCP, linking the readme to an FAQ page answering >> that question and raising a PR. >> >> >> Thanks, >> Aditya >> >> On Wed, Jun 3, 2026 at 6:28 AM Aditya Parikh <[email protected]> >> wrote: >> >>> To use the released jar instead of building from source follow the same >>> steps to add path to the downloaded solr-mcp-1.0.0.jar in the config. >>> >>> Instructions for Claude code are in >>> https://github.com/apache/solr-mcp README >>> As well as will be available when this PR >>> https://github.com/apache/solr-site/pull/175/files >>> (content/pages/mcp/clients/claude-code.md) >>> gets merged. >>> >>> claude mcp add --transport stdio -e SOLR_URL=http://localhost:8983/solr/ >>> solr-mcp -- java -jar /absolute/path/to/solr-mcp-1.0.0.jar >>> >>> Please let us know if there are difficulties and we can address them as >>> well as refine the documentation. >>> >>> Thanks, >>> Aditya >>> >>> On Wed, Jun 3, 2026 at 3:33 AM Jan Høydahl <[email protected]> wrote: >>> >>>> Way off topic to discuss the existence of the project itself in this >>>> context, I have >>>> clients looking very much forward to adding Solr MCP to their tool belt. >>>> >>>> What we are discussing is how to improve the *release process* to make >>>> sure >>>> we vote on the actual artifacts and not something else, and perhpas >>>> identify the >>>> need for a "smoke tester" script , like we have for both Solr and Solr >>>> Operator. >>>> That would lower the bar for both committers and others to participate in >>>> VOTEs. >>>> >>>> Please don't take this as critisism from my side, we're in this together >>>> and I lift >>>> issues with the goal of process improvement in mind. >>>> >>>> I have another question. The release artifacts are only jar files >>>> >>>> solr-mcp-1.0.0-javadoc.jar >>>> solr-mcp-1.0.0-javadoc.jar.asc >>>> solr-mcp-1.0.0-javadoc.jar.sha512 >>>> solr-mcp-1.0.0-plain.jar >>>> solr-mcp-1.0.0-plain.jar.asc >>>> solr-mcp-1.0.0-plain.jar.sha512 >>>> solr-mcp-1.0.0-sources.jar >>>> solr-mcp-1.0.0-sources.jar.asc >>>> solr-mcp-1.0.0-sources.jar.sha512 >>>> solr-mcp-1.0.0.jar >>>> solr-mcp-1.0.0.jar.asc >>>> solr-mcp-1.0.0.jar.sha512 >>>> >>>> Would not any ASF release need to release the entire source tree as a >>>> src.tgz >>>> so that anyone can download it in 10 years and build the binaries from >>>> source? >>>> I can see that the execuable jar is more self contained and all you need >>>> to run the mcp... >>>> >>>> Jan >>>> >>>>> 3. juni 2026 kl. 06:33 skrev Mark Miller <[email protected]>: >>>>> >>>>> Personally, I just see it as one more release vote we don't need. How >>>> many >>>>> Solr MCPs exist already? A dozen? >>>>> >>>>> Meh. I wouldn't use any of them anyway. It makes a much better Skill. >>>> MCPs >>>>> take up a crap load of context whether the current prompt uses it or >>>> not, >>>>> if you launch any agents, that silly token cost multiplies and context >>>> rot >>>>> extends out like a virus. As a simple skill, all of that is resolved, >>>> and >>>>> because command line usage is well burrowed into the training data, >>>> LLM’s >>>>> are much better at using Solr that way than via an MCP - and heck, that >>>>> also means you hardly even need much of a skill definition given how >>>> well >>>>> they know the Solr apis. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
