Releasing Chenile — the 11-repository release train

Chenile ships as one version across 11 repositories, all inheriting from chenile-parent. This is the maintainer workflow for cutting a release. Contributors rarely need it; it documents how the version you depend on gets to Maven Central.

Order

Always work in dependency order — for building, tagging and deploying:

1. chenile-parent · 2. chenile-core · 3. chenile-query-workflow-blueprints · 4. chenile-service-registry · 5. chenile-proxies · 6. chenile-security · 7. chenile-messaging · 8. chenile-bdd · 9. chenile-others · 10. chenile-process-management · 11. cconfig

Rules

• chenile-parent is the release gate. No sibling is deployed until the new parent is visible on Maven Central — a successful deploy is not the same as an indexed artifact.
• Annotated tags only. git describe prefers annotated tags; a lightweight new tag next to an older annotated one makes a repository describe itself as 2.1.13-1-g<sha>.
• Scoped commits. A version bump commits only the version changes — never sweep unrelated working-tree changes into a release.
• Shared documentation stays outside the code repositories.

Checklist

# 1. versions: chenile-parent/pom.xml properties + chenile-version.txt;
#    then each sibling's parent version + its *-version.txt
git status --short                          # 2. only the intended changes
mvn install        # or: make build         # 3. in order, fix failures before moving on
git add pom.xml ./*-version.txt
git commit -m "Upgraded to <version>"       # 4.
git tag -a <version> -m "<version>"         # 5. annotated
git push && git push origin <version>       # 6. (--set-upstream origin main if needed)
git describe                                # 7. must print exactly <version>

A wrong tag is fixed with git tag -d <version> && git tag -a <version> -m "<version>" && git push --force origin refs/tags/<version>.

Deploy

1. make deploy in chenile-parent (signing credentials come from the environment).
2. Wait until org.chenile:chenile-parent:<version> is downloadable from Maven Central.
3. make deploy in the other ten, in order. If a sibling fails to resolve the parent, Central hasn’t indexed it yet — wait and retry.

Handy multi-repo checks:

for d in chenile-parent chenile-core chenile-query-workflow-blueprints chenile-service-registry chenile-proxies \
         chenile-security chenile-messaging chenile-bdd chenile-others chenile-process-management cconfig; do
  printf '[%s] ' "$d"; git -C "$HOME/Documents/framework/$d" describe
done

After the framework

• JGen (chenile-gen) and its STM CLI are released separately and should be aligned to the new parent.
• Javadoc — bump the parent in chenile-javadoc/pom.xml; building the aggregation POM does not publish the Javadoc site by itself.
• This website — maven_version in _config.yml drives every “latest release” string. A daily workflow (scripts/update-version.sh) follows Maven Central but never downgrades, so a work-in-progress version set by hand survives. Add release notes under pages/release-notes/, and refresh Chenile by the numbers with python3 scripts/codebase-stats.py ...

Release status: 2.1.34

As of October 22, 2026, all 11 framework repositories build and pass their Maven tests against 2.1.34. JGen, STM CLI and the Javadoc aggregation build also pass; the process UI passes its tests and production build. The version-alignment commits are pushed, and the website and JGen default select 2.1.34. The 11 framework repositories, chenile-gen, and chenile-javadoc are tagged and pushed as 2.1.34.

2.1.34 is tagged. The chenile-parent:2.1.34 signed bundle was accepted and validated by Central Publishing, but Maven Central still returns 404 for the artifact. Stop before deploying dependent repositories and wait until the parent POM is visible on Maven Central. It refines the 2.1.33 process deployment story — the chenile-process-worker-set blueprint, a shared concrete worker service, Kafka retry and dead-lettering for worker failures, and header-scoped queue publication. See the 2.1.34 release notes.