From fc894e47fb2c4028cdc6eca8baabbeb183d23389 Mon Sep 17 00:00:00 2001 From: Joe Previte Date: Wed, 12 May 2021 15:34:35 -0700 Subject: [PATCH 1/2] docs(maintaining): add pull requests section --- CHANGELOG.md | 1 + docs/MAINTAINING.md | 7 +++++++ 2 files changed, 8 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 12e3d507..59a3560c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -68,6 +68,7 @@ VS Code v1.56 ### Documentation - docs(install): add raspberry pi section #3376 @jsjoeio +- docs(maintaining): add pull requests section #3378 @jsjoeio ### Development diff --git a/docs/MAINTAINING.md b/docs/MAINTAINING.md index eb2be4af..d65eb3e1 100644 --- a/docs/MAINTAINING.md +++ b/docs/MAINTAINING.md @@ -8,6 +8,7 @@ - [Triage](#triage) - [Project Boards](#project-boards) - [Versioning](#versioning) + - [Pull Requests](#pull-requests) @@ -63,3 +64,9 @@ It also gives us a way to separate the issue triage from bigger-picture, long-te `` 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. + +## Pull Requests + +Ideally, every PR should fix an issue. If it doesn't, make sure it's associated with a version milestone. + +If a PR does fix an issue, don't add it to the version milestone. Otherwise, the version milestone will have duplicate information: the issue & the PR fixing the issue. From 7be1ae36a225300bc56da50a912a8ccd10369249 Mon Sep 17 00:00:00 2001 From: Joe Previte Date: Wed, 12 May 2021 15:47:41 -0700 Subject: [PATCH 2/2] docs(maintaining): add merge strategies section --- CHANGELOG.md | 1 + docs/MAINTAINING.md | 7 ++++++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 59a3560c..535dac36 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -69,6 +69,7 @@ VS Code v1.56 - docs(install): add raspberry pi section #3376 @jsjoeio - docs(maintaining): add pull requests section #3378 @jsjoeio +- docs(maintaining): add merge strategies section #3379 @jsjoeio ### Development diff --git a/docs/MAINTAINING.md b/docs/MAINTAINING.md index d65eb3e1..02b6b2b5 100644 --- a/docs/MAINTAINING.md +++ b/docs/MAINTAINING.md @@ -9,6 +9,7 @@ - [Project Boards](#project-boards) - [Versioning](#versioning) - [Pull Requests](#pull-requests) + - [Merge Strategies](#merge-strategies) @@ -63,10 +64,14 @@ It also gives us a way to separate the issue triage from bigger-picture, long-te `` -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](https://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. ## Pull Requests Ideally, every PR should fix an issue. If it doesn't, make sure it's associated with a version milestone. If a PR does fix an issue, don't add it to the version milestone. Otherwise, the version milestone will have duplicate information: the issue & the PR fixing the issue. + +### Merge Strategies + +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.