editor.js/docs/releases.md

Branches, versions and releases — complete guideline

Branches

The project has two main branches: master and next.

Branch master contains the latest stable version of the editor. The latest version published to NPM available by default or by the tag latest.

Branch next used for development the next (release candidate) version of the editor. It may contain bug fixes, improvements or features. This version is available in NPM by next tag.

Versions

We use semantic versioning as a main guide for naming updates.

<major>.<minor>.<patch>

You need to bump the part of version according the changes:

• patch — for bug fixes, docs updates, code style fixes and other changes which do not affect the result project bundle
• minor — for new features with no backward compatibility problems.
• major — for breaking changes without backward compatibility with the api of the previous version of the project.

Pre-release versions may contain additional -rc.* suffix.

Release publishing

Drafts for new releases are created automatically via create-a-release-draft.yml workflow when pull request to next branch was merged with an updated version in the package.json file.

There is a workflow that fired on a new release publishing on GitHub.

Use target version changelog as a description.

Then you can publish the release and wait for package publishing via action.

This package version will be published to NPM with default latest tag.

Release candidate publishing

If you want to publish release candidate version, use suffix -rc.* for package version in package.json file and in tag on releases page. Workflow will detect it and mark a release as "pre-release".

This package version will be published to NPM with next tag.

Stable version: 2.19.0 Release candidate: 2.19.1-rc.0, 2.19.1-rc.1, ... Next version: 2.19.1

Auto-bump version

After each PR merge to the next branch bump-version-on-merge-next.yml workflow will check if a package version was updated. If there is no update then it will open a new PR with a next prerelease version.

How it works

The command for bumping a version will be running in a workflow.

yarn version --prerelease --preid rc --no-git-tag-version

Prerelease version will be bumped or a new prerelease patch will be created:

• 2.19.1 -> 2.19.2-rc.0
• 2.19.2-rc.0 -> 2.19.2-rc.1

Change version

You can edit version (and PR name of course) if you need to publish not a pre-release version or any other.

If the next update is planned to raise the minor version (2.19.1 -> 2.20.0), then change it before version update merge.

• 2.19.1 will be bumped to 2.19.2-rc.0 be default, change 2.19.2-rc.0 to 2.20.0-rc.0

Ignore update

If you do not need to upgrade and publish the update with the merged pull request (docs update or any other non-important changes), you can close the pull request generated by the workflow.

Example pipeline

Let's imagine that package version is 2.19.0 and you want to add some bug fixes and publish an update as 2.19.1.

1. Merge a single update or a few pulls with fixes to the default branch next.
2. Workflow bump-version-on-merge-next.yml will bump the version up to 2.19.1-rc.0 in the package.json and open a new pull request.
3. After bump version PR merge, the workflow create-a-release-draft.yml will automatically create a draft release on GitHub.
4. Check this new draft release on the releases page. Check tag v2.19.1-rc.0 and notice "This is pre-release" checkbox if it should be for a release candidate versions. Then publish that release.
5. Workflow will automatically push the package to NPM with tag next.
6. When you ready to publish a release, remove suffix from version name in package.json (2.19.1-rc.0 -> v2.19.1) in pull request from workflow bump-version-on-merge-next.yml. Follow steps 3-5 with workflows and publish a new version as latest update.
7. Merge branch next to master and save sources for history.