Skip to content

63362 proposal revisions#5

Open
haphut wants to merge 28 commits into63362-branching-versioning-deployment-proposalfrom
63362-proposal-revisions
Open

63362 proposal revisions#5
haphut wants to merge 28 commits into63362-branching-versioning-deployment-proposalfrom
63362-proposal-revisions

Conversation

@haphut
Copy link
Contributor

@haphut haphut commented Feb 24, 2026

Suggestions that I did not dare to push on top of your changes directly.

Remove API versioning (sections 8-10) and Pulsar topic versioning
(section 11) from this proposal. These topics will be covered in a
separate proposal document. Update the introduction and summary
accordingly.
Staging deploys proper semver releases, not release candidates.
Remove the RC tag type from the Git Tags table and summary.
Rename 'Hot-fix' tag type to 'Patch' for consistency with SemVer.
- Version tags use plain semver without v prefix: 1.2.3 (not v1.2.3)
- Commit tags use sha- prefix: sha-1d4cac8
- Introduce edge tag as rolling tag for latest main commit
- Git tags retain the v prefix (v1.2.3)
Add staging environment between development and production.
- Development deploys edge tag automatically on merge to main
- Staging deploys immutable semver tags for validation
- Production deploys the same semver tag after CAB approval
Describe the promotion flow as numbered steps.
Clarify that rollback is manual.
Hot-fixes use short-lived fix/ branches created from the current
production tag. The branch is deleted once the patch version tag
exists. Production catches up with trunk on the next regular release.
The fix/ prefix aligns with the fix: Conventional Commits type.
A Git branch is a pointer to a commit, not a sequence of commits.
Expand section 1 to list the three branch types (main, feature,
fix/) with their roles and lifecycle. Link to Git documentation.
Version bumps are currently a manual decision. Automation via
Conventional Commits and semantic-release is deferred to a
future proposal.
CAB reviews releases that have already been validated in staging.
Clarify that the approved Docker image is promoted to production.
Align summary with revised deployment flow (three environments),
hot-fix process (fix/ branches), version scheme (manual, SemVer
2.0.0 link), and CAB process (staging-validated).
Currently we have development and production environments.
A staging environment will be added in the future, where
production becomes a delayed version of staging. Present both
states clearly so the proposal reflects reality while showing
the direction we are moving toward.
Regular releases from main always bump at least MINOR. PATCH is
reserved exclusively for hot-fixes via fix/ branches. This gives
each MINOR release its own isolated patch space, preventing version
conflicts when multiple environments run different versions.

Explain why SemVer pre-release and build metadata modifiers cannot
solve this problem, and why this convention is SemVer-compatible
in trunk-based development.
@haphut haphut requested a review from chihaiaalex February 24, 2026 11:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants