From aceaf91001ce94b1b3c6ba0d7ec3f1071a9e16eb Mon Sep 17 00:00:00 2001 From: Andreas Braun Date: Thu, 28 Sep 2023 14:00:54 +0200 Subject: [PATCH 1/3] Update release notes to reflect new branch namings --- RELEASING.md | 101 ++++++++++----------------------------------------- 1 file changed, 20 insertions(+), 81 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 35dfbf342..0657bb580 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -1,8 +1,7 @@ # Releasing -The following steps outline the release process for both new minor versions (e.g. -releasing the `master` branch as X.Y.0) and patch versions (e.g. releasing the -`vX.Y` branch as X.Y.Z). +The following steps outline the release process for both new minor versions and +patch versions. The command examples below assume that the canonical "mongodb" repository has the remote name "mongodb". You may need to adjust these commands if you've given @@ -37,26 +36,10 @@ page. This uses [semantic versioning](https://semver.org/). Do not break backwards compatibility in a non-major release or your users will kill you. -Before proceeding, ensure that the `master` branch is up-to-date with all code +Before proceeding, ensure that the default branch is up-to-date with all code changes in this maintenance branch. This is important because we will later -merge the ensuing release commits up to master with `--strategy=ours`, which -will ignore changes from the merged commits. - -## Update composer.json - -This is especially important before releasing a new minor version. - -Ensure that the extension and PHP library requirements, as well as the branch -alias in `composer.json` are correct for the version being released. For -example, the branch alias for the 4.1.0 release in the `master` branch should -be `4.1.x-dev`. - -Commit and push any changes: - -```console -$ git commit -m "Update composer.json X.Y.Z" composer.json -$ git push mongodb -``` +merge the ensuing release commits with `--strategy=ours`, which will ignore +changes from the merged commits. ## Tag the release @@ -69,78 +52,34 @@ $ git push mongodb --tags ## Branch management -# Creating a maintenance branch and updating master branch alias - -After releasing a new major or minor version (e.g. 4.0.0), a maintenance branch -(e.g. v4.0) should be created. Any development towards a patch release (e.g. -4.0.1) would then be done within that branch and any development for the next -major or minor release can continue in master. - -After creating a maintenance branch, the `extra.branch-alias.dev-master` field -in the master branch's `composer.json` file should be updated. For example, -after branching v4.0, `composer.json` in the master branch may still read: - -``` -"branch-alias": { - "dev-master": "4.0.x-dev" -} -``` - -The above would be changed to: - -``` -"branch-alias": { - "dev-master": "4.1.x-dev" -} -``` - -Commit this change: - -```console -$ git commit -m "Master is now 4.1-dev" composer.json -``` +# Creating a maintenance branch and updating default branch name -### After releasing a new minor version - -After a new minor version is released (i.e. `master` was tagged), a maintenance -branch should be created for future patch releases: +When releasing a new major or minor version (e.g. 4.0.0), the default branch +should be renamed to the next version (e.g. 4.1). Renaming the default branch +using GitHub's UI ensures that all open pull request are changed to target the +new version. +Once the default branch has been renamed, create the maintenance branch for the +version to be released (e.g. 4.0): ```console -$ git checkout -b vX.Y -$ git push mongodb vX.Y -``` - -Update the master branch alias in `composer.json`: - -```diff - "extra": { - "branch-alias": { -- "dev-master": "4.0.x-dev" -+ "dev-master": "4.1.x-dev" - } - }, -``` - -Commit and push this change: - -```console -$ git commit -m "Master is now X.Y-dev" composer.json -$ git push mongodb +$ git checkout -b X.Y +$ git push mongodb X.Y ``` ### After releasing a patch version -If this was a patch release, the maintenance branch must be merged up to master: +If this was a patch release, the maintenance branch must be merged up to the +default branch (e.g. 4.1): ```console -$ git checkout master -$ git pull mongodb master -$ git merge vX.Y --strategy=ours +$ git checkout 4.1 +$ git pull mongodb 4.1 +$ git merge 4.0 --strategy=ours $ git push mongodb ``` The `--strategy=ours` option ensures that all changes from the merged commits -will be ignored. This is OK because we previously ensured that the `master` +will be ignored. This is OK because we previously ensured that the `4.1` branch was up-to-date with all code changes in this maintenance branch before tagging. From 91ab2825595838edc19d647f7433fb5a9b3c3662 Mon Sep 17 00:00:00 2001 From: Andreas Braun Date: Thu, 28 Sep 2023 14:03:57 +0200 Subject: [PATCH 2/3] Remove branch-alias from composer.json --- composer.json | 3 --- 1 file changed, 3 deletions(-) diff --git a/composer.json b/composer.json index 33a797d46..c58e9d761 100644 --- a/composer.json +++ b/composer.json @@ -50,9 +50,6 @@ } }, "extra": { - "branch-alias": { - "dev-master": "4.0.x-dev" - }, "laravel": { "providers": [ "MongoDB\\Laravel\\MongoDBServiceProvider", From b43c1b0c1defdc5a4ef7ab8571269e290433b136 Mon Sep 17 00:00:00 2001 From: Andreas Braun Date: Thu, 28 Sep 2023 17:00:30 +0200 Subject: [PATCH 3/3] Add line break to force new paragraph Co-authored-by: Jeremy Mikola --- RELEASING.md | 1 + 1 file changed, 1 insertion(+) diff --git a/RELEASING.md b/RELEASING.md index 0657bb580..e0b494d08 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -58,6 +58,7 @@ When releasing a new major or minor version (e.g. 4.0.0), the default branch should be renamed to the next version (e.g. 4.1). Renaming the default branch using GitHub's UI ensures that all open pull request are changed to target the new version. + Once the default branch has been renamed, create the maintenance branch for the version to be released (e.g. 4.0):