mirror of
https://github.com/codex-team/editor.js
synced 2024-05-15 12:57:38 +02:00
1772edf912
* Update releases.md If the next update is planned to raise the minor version (`2.19.1` -> `2.20.0`), then change it before version update merge. * Update docs/releases.md Co-authored-by: Peter Savchenko <specc.dev@gmail.com> Co-authored-by: Peter Savchenko <specc.dev@gmail.com>
101 lines
4.4 KiB
Markdown
101 lines
4.4 KiB
Markdown
# 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](https://semver.org) 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](.github/workflows/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](.github/workflows/publish-package-to-npm.yml) 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](.github/workflows/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](.github/workflows/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](.github/workflows/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](.github/workflows/publish-package-to-npm.yml) 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](.github/workflows/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.
|