Skip to content

Latest commit

 

History

History
61 lines (44 loc) · 3.42 KB

RELEASE.md

File metadata and controls

61 lines (44 loc) · 3.42 KB
Raw

Release Process

This policy applies to Beacon, BeaconLiveAdmin, and any other project in the BeaconCMS organization.

Guidelines

  1. Follow Semantic Versioning

    • For projects on v0.x releases, breaking changes are released as minor versions, for example in v0.2.0
    • For projects on v1.x releases, breaking changes are released as major versions, for example in v2.0.0

  2. Each project has its own lifecycle and releases, one may evolve faster than others.

  3. A new major or minor version is released once a month on the first Wednesday of the month, containing features, fixes, and potentially breaking changes.

    • The type of the version, either major or minor is decided based on the changes included in that release and the current version.
    • We might skip releasing a new version if there are no changes in that period of time.

  4. Bug fixes and security patches are released as soon as possible, either as a patch or minor version depending on the current version.

Git strategy

Changes are applied to the main branch through feature branches. A pull request is opened, reviewed, and merged into main once it's ready to avoid merge conflicts and make that code available on main in case anyone wants to test or use it.

Along with the main and feature branches, we also keep release branches for each version, for example v0.1.x, v2.0.x, and so on. Changes are cherry-picked from main into the release branches as needed, for example if the current published version is v0.1.1 and a bug fix is merged into main, it will be cherry-picked into the v0.1.x branch and a new v0.1.2 version will be released. Similarly, if a new feature is merged or a breaking change is introduced, it will also be cherry-picked into a release branch but this time into the v0.2.x branch because new features and breaking changes require a version bump.

Release steps

  1. Checkout the main branch and make sure it's up to date with upstream
  2. Run mix assets.build
  3. Update the CHANGELOG.md file and move all items from "Unreleased" to a new version section (the one being released), and leave unfinished or incomplete item in "Unrelease" section (the ones that will not be included in the release).
  4. Commit the changes to upstream main if necessary
  5. Checkout the release branch and make sure it's up to date with upstream. The release branch is usually the minor version of current version, for eg: v0.1 branch for a v0.1.5 release. Create a new branch if releasing a new minor or major version.
  6. Make sure all the relevant changes have been cherry-picked from main to the release branch
  7. Update the CHANGELOG.md to remove the "Unreleased" section, it should display this release as latest version.
  8. Update the version in the files mix.exs and package.json and throughout docs/ files
  9. Run mix assets.build
  10. Make sure all relevant changes, especially breaking changes, are documented in an upgrade guide in guides/upgrading
  11. Commit the changes
  12. Create a new git tag and push upstream
git tag -a v0.1.0 -m "v0.1.0"
git push --tags
  1. Publish the package to Hex.pm package registry
mix hex.publish
  1. Create a new GitHub release from the tag and include the changes from the CHANGELOG.md in the release notes