File: PUBLISHING.md

package info (click to toggle)
node-marked 0.8.0%2Bds%2Brepack-2
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, bullseye, sid
  • size: 1,948 kB
  • sloc: javascript: 3,640; sh: 16; makefile: 16
file content (24 lines) | stat: -rw-r--r-- 1,271 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Releasing Marked

- [ ] See [contributing](#/CONTRIBUTING.md)
- [ ] Create release branch from `master` (`release-x.y.z`)
- [ ] Submit PR with minimal name: Release x.y.z
- [ ] Complete PR checklists

## Overall strategy

**Master is always shippable:** We try to merge PRs in such a way that `master` is the only branch to really be concerned about *and* `master` can always be released. This allows smoother flow between new features, bug fixes, and so on. (Almost a continuous deployment setup, without automation.)

## Versioning

We follow [semantic versioning](https://semver.org) where the following sequence is true `[major].[minor].[patch]`; therefore, consider the following implications of the release you are preparing:

1. **Major:** There is at least one change not deemed backward compatible.
2. **Minor:** There is at least one new feature added to the release.
3. **Patch:** No breaking changes, no new features.

What to expect while Marked is a zero-major (0.x.y):

1. The major will remain at zero; thereby, alerting consumers to the potentially volatile nature of the package.
2. The minor will tend to be more analogous to a `major` release.
3. The patch will tend to be more analogous to a `minor` release or a collection of bug fixes (patches).