docs: add changelog to MAINTAINING.md (#3467)
Co-authored-by: Akash Satheesan <akash@coder.com>
This commit is contained in:
parent
8ed578b686
commit
0e67ab7b85
13
CHANGELOG.md
13
CHANGELOG.md
|
@ -37,10 +37,23 @@ VS Code v0.00.0
|
||||||
|
|
||||||
VS Code v0.00.0
|
VS Code v0.00.0
|
||||||
|
|
||||||
|
### New Features
|
||||||
|
|
||||||
|
- item
|
||||||
|
|
||||||
|
### Bug Fixes
|
||||||
|
|
||||||
|
- item
|
||||||
|
|
||||||
### Documentation
|
### Documentation
|
||||||
|
|
||||||
- docs: fix confusing sentence in pull requests section #3460 @shiv-tyagi
|
- docs: fix confusing sentence in pull requests section #3460 @shiv-tyagi
|
||||||
- docs: remove toc from changelog @oxy @jsjoeio
|
- docs: remove toc from changelog @oxy @jsjoeio
|
||||||
|
- docs(MAINTAINING): add information about CHANGELOG #3467 @jsjoeio
|
||||||
|
|
||||||
|
### Development
|
||||||
|
|
||||||
|
- item
|
||||||
|
|
||||||
## 3.10.2
|
## 3.10.2
|
||||||
|
|
||||||
|
|
|
@ -10,6 +10,7 @@
|
||||||
- [Versioning](#versioning)
|
- [Versioning](#versioning)
|
||||||
- [Pull Requests](#pull-requests)
|
- [Pull Requests](#pull-requests)
|
||||||
- [Merge Strategies](#merge-strategies)
|
- [Merge Strategies](#merge-strategies)
|
||||||
|
- [Changelog](#changelog)
|
||||||
- [Release](#release)
|
- [Release](#release)
|
||||||
- [Release Manager Rotation](#release-manager-rotation)
|
- [Release Manager Rotation](#release-manager-rotation)
|
||||||
|
|
||||||
|
@ -79,6 +80,14 @@ If a PR does fix an issue, don't add it to the version milestone. Otherwise, the
|
||||||
For most things, we recommend "Squash and Merge". If you're updating `lib/vscode`, we suggest using the "Rebase and Merge" strategy. There may be times where "Create a merge commit" makes sense as well. Use your best judgement. If you're unsure, you can always discuss in the PR with the team.
|
For most things, we recommend "Squash and Merge". If you're updating `lib/vscode`, we suggest using the "Rebase and Merge" strategy. There may be times where "Create a merge commit" makes sense as well. Use your best judgement. If you're unsure, you can always discuss in the PR with the team.
|
||||||
The code-server project follows traditional [semantic versioning](ttps://semver.org/), with the objective of minimizing major changes that break backward compatibility. We increment the patch level for all releases, except when the upstream Visual Studio Code project increments its minor version or we change the plugin API in a backward-compatible manner. In those cases, we increment the minor version rather than the patch level.
|
The code-server project follows traditional [semantic versioning](ttps://semver.org/), with the objective of minimizing major changes that break backward compatibility. We increment the patch level for all releases, except when the upstream Visual Studio Code project increments its minor version or we change the plugin API in a backward-compatible manner. In those cases, we increment the minor version rather than the patch level.
|
||||||
|
|
||||||
|
### Changelog
|
||||||
|
|
||||||
|
To save time when creating a new release for code-server, we keep a running changelog at `CHANGELOG.md`.
|
||||||
|
|
||||||
|
If either author or reviewer of a PR believe the change should be mentioned in the `CHANGELOG`, then it should be added.
|
||||||
|
|
||||||
|
If there is not a "Next Version" when you modify `CHANGELOG`, please add it using the template you see near the top of `CHANGELOG`. You can use the suggested format: `<pr title> <pr #> <author> Example: `fix: Check the logged user instead of $USER #3330 @videlanicolas`
|
||||||
|
|
||||||
## Release
|
## Release
|
||||||
|
|
||||||
### Release Manager Rotation
|
### Release Manager Rotation
|
||||||
|
|
Loading…
Reference in New Issue