Hi Roy, On Fri, 2026-06-26 at 21:28 +0200, Roy Teeuwen wrote: > Hi all, > > I've been working on extending the Sling Committer CLI > (https://github.com/apache/sling-org-apache-sling-committer-cli) so > it can drive a release end-to-end, and I'd like to get some feedback > before going further. > > What's new in the CLI > > The CLI previously stopped at the vote email. The PR adds the post- > vote half of the workflow so the whole release can be driven from the > tool: > > - "tally-votes" is now PMC-aware: the [RESULT] email auto-detects > (via Whimsy) whether the release manager is a PMC member and asks a > PMC member to do the dist upload if not > - "close-staging" — closes an open staging repo, deriving the > description from the staged POM's <name>/<version> (works even before > the repo is in the Lucene index) > - "verify" — checks PGP signatures, SHA-1/MD5 and CI status > - "promote / drop" — promote a closed repo to Maven Central, or drop > it on a failed vote > - "update-dist" — copies the release to dist.apache.org (PMC-only; > previous version auto-deduced)
This is very cool! > > And, to make it as easy as possible: "finalize" — one step that runs > promote → update-dist (PMC) → next JIRA version → release JIRA > version → update Apache Reporter > > I have a matching change for the website's release-management > (https://github.com/apache/sling-site) page that documents the CLI as > the recommended path, updates the GPG/settings.xml prerequisites for > maven-gpg-plugin 3.x, and clarifies the PMC-vs-committer split for > the dist upload. > > The PR also includes a skills/sling-release/SKILL.md — a playbook > that lets an AI coding agent drive the release using the CLI: > prerequisites to verify, the ordered Maven + CLI steps, DRY_RUN- > before-AUTO safety rules, and a quick command reference. It encodes > the same process the README documents, just in a form an agent can > follow. > > Open questions: > > 1. Do we want an agent skill file living in the committer-cli repo? > The current ones are in the whiteboard, not sure if we want to go for > SKILLs per dedicated repo, or one big repo with SKILLs I would slightly prefer a skill repos. The reason is that I would not expect everyone to clone the committer CLI - we should push it to docker hub so the clone + build step is omitted. So then it makes sense to install skills from a central repo. > 2. I am not a PMC member, so I am not able to test the actual dist > command (either seperatly or in the finalize command). Is there a PMC > member who is willing to test it? The resource resolver still has a > release active that can be closed and has all the votes > 3. Go ahead and review my PRs and give feedback if wanted, I updated > the release documentation to more point to the automated flow than > manual steps: I did not yet look in depth at the PRs but for the skill I'd encourage you to take a look at [1]. It's really fresh and active and it might make sense to join efforts. Thanks, Robert > - > https://github.com/apache/sling-org-apache-sling-committer-cli/pull/28 > - https://github.com/apache/sling-site/pull/282 > > Greets, > Roy [1]: https://magpie.apache.org/skills/release-management/readme/
