deblan-mirror/editor.js
deblan-mirror/editor.js
1
0
Fork 0
mirror of https://github.com/codex-team/editor.js synced 2024-06-11 02:12:31 +02:00
Code Issues Projects Releases Wiki Activity
editor.js/docs/releases.md
Taly c4a57c16a9
Feature: create a release draft workflow (#1555) 
* Rename workflow file

* Create create-a-release-draft.yml

* Update releases.md
2021-02-22 23:27:24 +03:00

3.2 KiB
Raw Blame History

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

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 and bump the version up to 2.19.1-rc.0 in the package.json. For the rest rc updates you should bump version number in suffix (to 2.19.1-rc.1 etc).
  2. Workflow create-a-release-draft.yml will automatically create a draft release on GitHub.
  3. 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.
  4. Workflow will automatically push the package to NPM with tag next.
  5. When you ready to publish a release, remove suffix from version name in package.json (2.19.1-rc.0 -> v2.19.1) and push changes. Follow steps 2-4 with workflows and publish a new version as latest update.
  6. Merge branch next to master and save sources for history.