Status
Deferred cross-project follow-up. Not active and not part of Migration 002.
Why this is useful
Several repositories already have release workflows, but there is not yet one clear cross-project path for a release that starts with a requested version such as v1.4.0 and may require domain-specific version preparation before the final tag is created.
For example, a Java repository may need Maven version metadata prepared before the exact release commit can be verified and tagged. Generic Git/release orchestration should not need to know Maven details, while the Java tooling should not own generic tagging/publication behaviour.
Goal
Define and prove one release flow that goes from:
- requested version;
- domain-specific version preparation where needed;
- exact prepared commit;
- verification of that exact commit;
- tag/release publication.
Likely owners
tool.git-project: generic release request, exact-commit handoff, tagging and generic release lifecycle;- domain tooling such as
tool.java-project: prepare domain-specific version/source metadata;
- consuming repository: product-specific release notes/assets where needed;
brainboxemb.meta: only the cross-project convention and rollout record.
First useful slice
When this follow-up is activated, select one real domain/consumer and make that path work end to end before generalising it. Java is a likely first candidate because source/build metadata may need explicit version preparation, but the current repositories should be rechecked before choosing the qualifier.
Not part of the first slice
- redesigning every existing release workflow at once;
- forcing all domains to use identical version-file mechanics;
- moving domain-specific version logic into
tool.git-project;
- changing unrelated build or publication infrastructure.
When to pick this up
Activate when a real repository needs a release where the requested version must drive preparation of the source/build metadata before tagging.
Done when
One real consumer can request a version and complete the prepare → verify exact commit → tag/publish flow through clearly separated generic and domain tooling, with the reusable contract documented for later domains.
Status
Deferred cross-project follow-up. Not active and not part of Migration 002.
Why this is useful
Several repositories already have release workflows, but there is not yet one clear cross-project path for a release that starts with a requested version such as
v1.4.0and may require domain-specific version preparation before the final tag is created.For example, a Java repository may need Maven version metadata prepared before the exact release commit can be verified and tagged. Generic Git/release orchestration should not need to know Maven details, while the Java tooling should not own generic tagging/publication behaviour.
Goal
Define and prove one release flow that goes from:
Likely owners
tool.git-project: generic release request, exact-commit handoff, tagging and generic release lifecycle;tool.java-project: prepare domain-specific version/source metadata;brainboxemb.meta: only the cross-project convention and rollout record.First useful slice
When this follow-up is activated, select one real domain/consumer and make that path work end to end before generalising it. Java is a likely first candidate because source/build metadata may need explicit version preparation, but the current repositories should be rechecked before choosing the qualifier.
Not part of the first slice
tool.git-project;When to pick this up
Activate when a real repository needs a release where the requested version must drive preparation of the source/build metadata before tagging.
Done when
One real consumer can request a version and complete the prepare → verify exact commit → tag/publish flow through clearly separated generic and domain tooling, with the reusable contract documented for later domains.