Skip to content

Release guidelines

Release rules for the platform, Easy plugins and RYSes. Branch roles are in Branch naming conventions.

Versioning

All releases use semantic versioning.

  • MAJOR: whole new features, refactoring, breaking changes.
  • MINOR: small new features, migrations, minor changes of internal logic.
  • PATCH: bug fixes and harmless changes (documentation, readme). A patch release cannot include migrations or breaking changes.

Platform and plugin releases

Releases of the platform and Easy plugins are triggered manually through Gitmakers.

Patch releases

Patch releases go out weekly from next/bugs. Trials are not updated from next/bugs. Cloud clients are always up to date, so the update is announced and scheduled when a new next/bugs is released.

Changes for the next patch release must be delivered by Wednesday noon. A fix pushed on Wednesday the 1st is tested for a week and reaches production on Friday the 10th.

Minor releases

Minor releases go out monthly from next/minor-rc, in the last week of the month. Code freeze is around the 15th, followed by end-to-end testing.

Major releases

Major releases go out once a year, without a fixed date, from next/major-rc. They deliver large features announced by marketing. At least a month before the release the focus is on the marketing campaign, extensive end-to-end and integration testing, and training of sales and support staff.

RYS releases

RYSes are distributed through the Easy gem server (gems.easysoftware.com) or RubyGems. A RYS has to pass code review and be merged into master first. Then, locally:

  1. Check out and pull the latest master.
  2. Increase the version according to semantic versioning, either with easy increase-version or manually in lib/RYS_NAME/version.rb.
  3. Merge the changelogs, either with easy changelog-merge or manually: copy the entries from /changelogs into the matching sub-sections of the Unreleased section of CHANGELOG.MD in the RYS root.
  4. Commit and push the changes.
  5. Release with easy gems-release. Most RYSes release automatically from their master pipeline once it passes.

Easy products lock RYS versions, usually to a minor version. When you release a minor version or higher, increase the version in the relevant platform Gemfile too. Patch versions are usually fine without it.

A git tag in the format v2.5.5 is created on release.

Releasing an older version of a RYS

Use this when a fix must go into an older version, for example the latest master version is 2.0.0 and the fix is for 1.5.3.

  1. Check out the tag of the version to update:

    git checkout tags/v1.5.3 -b 111111_my_new_bugfix_branch

  2. Make the change, write a changelog, commit and push.

  3. Create a merge request marked as Draft. Do not merge it; it exists for code review and the CI pipeline.
  4. Follow the standard RYS release steps above, staying on your branch instead of master. Version 1.5.4 is released.
  5. Check out master and create a branch such as forward_1_5_4.
  6. Forward your changes: download the plain diff of the Draft merge request and apply it. Keep the 2.0.0 version and make sure the changelog entries are in chronological order.

  7. Write a changelog:

    easy changelog changed --body "forwarding changes from 1.5.4"

  8. Commit, push and create a merge request into master.

  9. After it is merged, follow the standard RYS release steps. Raise the version at least as high as the one you released before. If master contains other changes, coordinate the release with their authors.