feat: release all maintained components at one version

.github/ISSUE_TEMPLATE/release.yml

@@ -1,20 +1,20 @@
 name: Release tracking
-description: Agree on module versions, release scope, and compatibility before publication.
+description: Track one version for all maintained public components.
 title: "[Release]: "
 body:
   - type: markdown
     attributes:
       value: |
         Follow docs/RELEASING.md. Keep this issue open through the preparation
         PR using Refs, then close it only after publication and consumer checks.
-        This community project publishes modules independently; merging source
-        does not publish a version.
-  - type: textarea
-    id: modules
+        All maintained public modules release together at one version. Merging
+        an ordinary source PR does not publish a version.
+  - type: input
+    id: version
     attributes:
-      label: Modules and target versions
-      description: List each directory and version, including unpublished internal dependencies. Development and deprecated frozen modules are excluded.
-      placeholder: "logger v0.1.0; . v0.1.0"
+      label: Unified release version
+      description: State the shared target or auto/patch/minor/major increment. Every maintained public module is included; development and frozen modules are excluded.
+      placeholder: "patch (all maintained components)"
     validations:
       required: true
   - type: textarea
@@ -28,7 +28,7 @@ body:
     id: history
     attributes:
       label: Previous versions and accumulated changes
-      description: Each module uses its own previous published tag. Link relevant PRs and identify missing historical summaries or commits without PRs.
+      description: Link the previous project version and relevant PRs. The root Release groups actual changes by component and shows the full version table.
     validations:
       required: true
   - type: textarea
@@ -43,7 +43,7 @@ body:
     attributes:
       label: Before publication
       options:
-        - label: I understand that publication needs an explicit Actions dispatch after the preparation PR is merged.
+        - label: I understand that merging a preparation PR with automatic publication enabled authorizes the full unified release after checks pass; manual publication remains available.
           required: true
         - label: I removed credentials and private data from release scope and evidence.
           required: true

.github/workflows/prepare-release.yml

@@ -3,11 +3,6 @@ name: Prepare release
 on:
   workflow_dispatch:
     inputs:
-      scope:
-        description: Module directory, comma-separated directories, or all
-        required: true
-        default: all
-        type: string
       bump:
         description: Version increment (auto uses accumulated release notes)
         required: true
@@ -54,22 +49,13 @@ jobs:
       - name: Prepare metadata, tracking issue, and PR
         env:
           GH_TOKEN: ${{ github.token }}
-          RELEASE_SCOPE: ${{ inputs.scope }}
           RELEASE_BUMP: ${{ inputs.bump }}
           RELEASE_AUTOMATIC: ${{ inputs.auto_publish }}
         run: |
           python3 - <<'PY'
           import os
           import subprocess
-          scope = os.environ['RELEASE_SCOPE'].strip()
-          command = ['python3', 'tools/release.py', 'prepare', '--bump', os.environ['RELEASE_BUMP']]
-          if scope == 'all':
-              command.append('--all')
-          else:
-              for directory in scope.split(','):
-                  if not directory.strip():
-                      raise SystemExit('Select module directories or all.')
-                  command.extend(['--module', directory.strip()])
+          command = ['python3', 'tools/release.py', 'prepare', '--all', '--bump', os.environ['RELEASE_BUMP']]
           if os.environ['RELEASE_AUTOMATIC'] == 'true':
               command.append('--auto-publish')
           subprocess.run(command, check=True)

docs/CHECKLIST.md

@@ -274,3 +274,4 @@ Race-detector execution is intentionally excluded because CGO must remain disabl
 - [x] REL-DRAFT: Resolve matching Release drafts through authenticated listing because GitHub's by-tag endpoint returns published Releases. Reject duplicate matches and retain reviewed-note/tag conflict checks before publication. Thirty release regressions passed, including the real GoReleaser OSS v2.18.2 draft/finalization fixture with draft-by-tag 404 responses (2026-10-04). The first hosted attempt created the reviewed root tag/draft at PR #16's SHA and then stopped at the old draft lookup; preserve those objects for recovery. Restrict progress artifacts to reports, notes, configurations, and logs. Public consumer acceptance remains separate below; see issue #19.
 - [x] REL-VISIBILITY: Bound post-GoReleaser read-after-write waiting to 30 seconds, validate every observed Release against frozen notes, and propagate conflicts/API errors immediately without repeating writes. Thirty-three offline release regressions passed, including delayed draft/finalization, timeout preservation, and immediate error propagation (2026-10-04). Hosted run 37206952188 published and consumer-verified root v0.1.0, then stopped before the new commons/regex draft became visible; issue #20 tracks recovery.
 - [x] REL-PUBLIC: Publish all 27 maintained public modules as v0.1.0 from merged preparation PR #16 at immutable SHA 34fcc751355a2b29bca393748139ff96dd8bbf2a. The hosted GoReleaser OSS v2.18.2 run finalized every Release only after independent public download, tidy, build, module/checksum verification, and rejection of local replacements, with CGO disabled, GOWORK=off and fresh session caches. Release issue #15 closed automatically after completion. The frozen tracer/xray adapter was excluded. See [RELEASE_ACCEPTANCE.json](RELEASE_ACCEPTANCE.json) (2026-10-04). Hosted preparation controls and native PR/main checks were exercised; browser form rendering and default-token authorization remain separate rollout checks.
+- [x] REL-UNIFIED: Replace new component-scoped releases with one version for all maintained public modules, preserving independent Go paths and prefixed tags. Add project release_version, aggregate auto-increment policy, cohort-wide reserved-version avoidance, synchronized internal requirements, schema-2 full-cohort validation, component/repository grouped root notes, and root finalization last with the stable Latest label. Twenty-one isolated automation and 37 release regressions passed, including Logger-only cohort bumps, divergent published baselines/reserved nested tags, partial/mixed-plan rejection, aligned requirements, failure/resume ordering, legacy schema-1 recovery, and real GoReleaser OSS v2.18.2 root/component/prerelease draft/finalization and Latest configuration. Eighteen contribution/form regressions and actionlint v1.7.12 passed (2026-10-05). This records implementation acceptance; no new public version was prepared or published. See issue #23 and [Releasing modules](RELEASING.md).

docs/MAINTAINING.md

@@ -83,7 +83,7 @@ and [required-check troubleshooting](https://docs.github.com/en/pull-requests/ho
 
 ## Rollout verification
 
-For independent version publication, follow [Releasing modules](RELEASING.md).
+For unified version publication across independent modules, follow [Releasing modules](RELEASING.md).
 Preparation automatically generates module versions, dependency metadata,
 accumulated notes, a tracking issue, and a PR. The publisher reuses required
 checks, binds the reviewed plan to the merged preparation SHA, and keeps the

docs/MODULES.md

@@ -4,6 +4,12 @@ The implementation uses twenty-eight public modules and three development module
 
 ## Module boundaries
 
+Future releases use [one shared version](RELEASING.md) for all maintained public
+modules. `tools/modules.json` records the project `release_version`, and each
+maintained module version matches it. Fixing only Logger still releases the full
+cohort; the root version Release groups actual component changes and lists every
+module. Development modules and the frozen X-Ray adapter remain excluded.
+
 All module paths start with `github.com/rambow-cloud/powertools-lambda-go`.
 
 | Directory | Responsibility | Initial tag |

docs/PUBLISHING_PLAN.md

@@ -1,6 +1,6 @@
 # Optional utilities and Go publishing
 
-Assessment date: 2026-09-14; publication identity updated 2026-09-27. Feature modules have independent dependencies and versions in one repository. Module boundaries are implemented; see [MODULES.md](MODULES.md) for the actual layout and maintenance commands. The selected repository path is `github.com/rambow-cloud/powertools-lambda-go`. The 27 maintained public modules were published as `v0.1.0` on 2026-10-04; see [public release acceptance](RELEASE_ACCEPTANCE.json). The frozen X-Ray adapter was excluded.
+Assessment date: 2026-09-14; publication identity updated 2026-09-27; unified version policy adopted 2026-10-05. Feature modules have independent dependencies and one shared release version in this repository. Module boundaries are implemented; see [MODULES.md](MODULES.md) for the actual layout and maintenance commands. The selected repository path is `github.com/rambow-cloud/powertools-lambda-go`. The 27 maintained public modules were published as `v0.1.0` on 2026-10-04; see [public release acceptance](RELEASE_ACCEPTANCE.json). The frozen X-Ray adapter was excluded.
 
 ## Consumer experience
 
@@ -27,9 +27,9 @@ The example uses the publicly verified Parser `v0.1.0` release. The existing uti
 | Compile utility packages absent from the application's transitive imports | Not required | Not required |
 | Source download boundary | Entire containing module | Selected modules and required dependencies |
 | Dependency requirements and minimum Go version | Shared `go.mod` | Each module owns its requirements |
-| Select independent utility versions | No | Yes |
+| Release version policy | One version | One shared version across independent modules |
 | Version tag for Parser v0.1.0 | `v0.1.0` | `parser/v0.1.0` |
-| Maintenance | One release/test boundary | Per-module releases and consumer compatibility checks |
+| Maintenance | One release/test boundary | One release cohort with per-module consumer compatibility checks |
 
 A single module does not automatically compile or link every listed dependency into a Lambda binary. Conversely, importing one package does not make the module's dependency metadata, source archive, or version independent. Graph pruning and lazy loading can avoid some unrelated dependency retrieval; they are not an extras mechanism or a guarantee that unrelated dependency metadata is never consulted.
 
@@ -46,7 +46,7 @@ The split follows these boundaries:
 3. Keep exactly one shared invocation context key and cold-start state. Feature modules under the existing repository import prefix can still access the root `internal/invocation` package: Go's `internal` rule is based on the parent import path, not simply on module boundaries. Moving it to `commons/internal` would prevent sibling utility imports; copying it would break wrapper composition. The root core must not import feature modules, including through tests.
 4. Isolate `tracer/xray` from the OTel Tracer module to keep the deferred legacy SDK optional at the module level. Initially keep the Parameters providers together; consider finer provider modules only if consumer dependency budgets justify them.
 5. Move examples and integration programs into development modules so their combined imports do not pull every utility back into the core module. Use `go.work` for local composition. Release verification must also work with `GOWORK=off` and published dependency versions, without local `replace` paths.
-6. Keep a consistent initial release version if helpful, but issue a tag for each changed module (`parser/v0.1.0`, `signer/v0.1.0`, and so on). Publish shared dependencies first. A future major v2 requires the corresponding `/v2` module/import suffix. Do not promise a transparent split after consumers already depend on root-module versions; perform it before initial publication.
+6. Release every maintained public module at one shared version, with its required tag (`parser/v0.1.1`, `signer/v0.1.1`, and so on). Publish shared dependencies first and finalize the root unified summary last. A future major v2 requires the corresponding `/v2` module/import suffix. The module split predates public publication; the unified version policy preserves those module paths and boundaries.
 
 Optional parser/schema and Kafka codec integrations should use explicit adapters with small interfaces, not feature build tags or a root package that imports all utilities. Build tags do not offer equivalent dependency isolation because module maintenance considers files across build tags.