Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Latest commit

 

History

History
133 lines (88 loc) · 4.43 KB

File metadata and controls

133 lines (88 loc) · 4.43 KB

Release Policy

Actionbase follows Semantic Versioning (SemVer) to communicate changes clearly.

Version scheme

Versions follow the format MAJOR.MINOR.PATCH:

  • MAJOR: Incompatible API changes
  • MINOR: New features, backward compatible
  • PATCH: Bug fixes, backward compatible

Example: 1.2.3 → Major 1, Minor 2, Patch 3

Current stage (0.x.x)

Actionbase has been running in production internally at Kakao. The open-source release is in preparation. During the 0.x.x phase:

  • APIs may change between releases
  • Installation and operations guides are being prepared
  • Feedback and experimentation are welcome

The 1.0.0 release will mark the point where external users can deploy Actionbase in production environments.

Release workflow

Releases are automated via GitHub Actions. Development uses -SNAPSHOT suffixes.

Branch model

main:    A ─ B ─ C ─ D ─ E ─ ...          (0.3.0-SNAPSHOT)
                 │
          tag v0.2.0
                 └── 0.2.x:  C ── F ──    (0.2.1-SNAPSHOT)
                                   │
                            tag v0.2.1
  • main — active development, always X.Y.0-SNAPSHOT
  • X.Y.x — release branch, created automatically on minor release

The Bump Version workflow takes only a version input — the target branch is derived from it (X.Y.0main, X.Y.Z with Z≥1X.Y.x).

Minor release

Three manual steps, everything else is automatic.

1. [manual]    Actions → "Bump Version" → version: 0.3.0
               → PR: "Bump version to 0.3.0" (against main)
2. [manual]    Merge PR
               → (auto) tag v0.3.0
               → (auto) create 0.3.x branch (0.3.1-SNAPSHOT)
               → (auto) PR: "Bump version to 0.4.0-SNAPSHOT"
3. [manual]    Merge snapshot PR
               → main is now 0.4.0-SNAPSHOT

Patch release

Two manual steps. Fixes go to main first, then cherry-pick to the release branch.

1. [manual]    Actions → "Bump Version" → version: 0.2.1
               → PR: "Bump version to 0.2.1" (against 0.2.x)
2. [manual]    Merge PR
               → (auto) tag v0.2.1
               → (auto) 0.2.x bumped to 0.2.2-SNAPSHOT

Approving the bump PR's CI

The bump PR is opened by github-actions[bot], so GitHub gates its workflow runs behind a one-time maintainer approval (this prevents workflow loops). Before you can merge the PR:

  1. Open the PR, or go to the Actions tab filtered by the PR
  2. Click Approve and run on the pending workflow runs

Approval is per PR — expect to do this once for every release.

Upstream-first

Fixes go to main first, then cherry-pick to release branches.

✅  main → cherry-pick → 0.2.x
❌  commit directly to 0.2.x only

Exception: when main has diverged significantly and cherry-pick is not feasible, apply directly to the release branch with a note in the commit message.

Compatibility promise

The following applies after 1.0.0:

  • PATCH releases are always safe to upgrade
  • MINOR releases add features without breaking existing functionality
  • MAJOR releases may include breaking changes; migration guides will be provided

Release candidates

Before a release, one or more release candidates (-rc.N) may be published for community testing and feedback.

To participate:

Support policy

Currently, only the latest release is actively supported with bug fixes and security patches.

As the project matures, we may introduce Long-Term Support (LTS) releases with extended maintenance windows.

Release artifacts

Each module releases independently.

Module Artifact Distribution
codec-java Java library Maven (Central planned)
core Java library Not yet published
server Docker image ghcr.io/kakao/actionbase
cli Binary GitHub Releases

Compatibility

codec-java Actionbase (server)
0.2.0 0.3.x

Release announcements are posted in GitHub Releases.