You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Add a note to save changes before starting (#17987)
During the release I figured that most of the times you might work on
features/bugfixes. In that case the current release process this
scenario isn't specified and who knows what it might or might not do.
I added point 1. and 9. where we ask Cursor to save the changes (1) and
go back to the state it was before (9). This would make the release
process more complete.
---------
Co-authored-by: Charly Gomez <charly.gomez@sentry.io>
Copy file name to clipboardExpand all lines: .cursor/rules/publishing_release.mdc
+7-2Lines changed: 7 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -12,13 +12,18 @@ Use these guidelines when publishing a new Sentry JavaScript SDK release.
12
12
13
13
The release process is outlined in [publishing-a-release.md](mdc:docs/publishing-a-release.md).
14
14
15
-
1. Make sure you are on the latest version of the `develop` branch. To confirm this, run `git pull origin develop` to get the latest changes from the repo.
15
+
1. Ensure you're on the `develop` branch with the latest changes:
16
+
- If you have unsaved changes, stash them with `git stash -u`.
17
+
- If you're on a different branch than `develop`, check out the develop branch using `git checkout develop`.
18
+
- Pull the latest updates from the remote repository by running `git pull origin develop`.
19
+
16
20
2. Run `yarn changelog` on the `develop` branch and copy the output. You can use `yarn changelog | pbcopy` to copy the output of `yarn changelog` into your clipboard.
17
21
3. Decide on a version for the release based on [semver](mdc:https://semver.org). The version should be decided based on what is in included in the release. For example, if the release includes a new feature, we should increment the minor version. If it includes only bug fixes, we should increment the patch version. You can find the latest version in [CHANGELOG.md](mdc:CHANGELOG.md) at the very top.
18
22
4. Create a branch `prepare-release/VERSION`, eg. `prepare-release/8.1.0`, off `develop`.
19
-
5. Update [CHANGELOG.md](mdc:CHANGELOG.md) to add an entry for the next release number and a list of changes since the last release from the output of `yarn changelog`. See the `Updating the Changelog` section in [publishing-a-release.md](mdc:docs/publishing-a-release.md) for more details. If you remove changelog entries because they are not applicable, please let the user know.
23
+
5. Update [CHANGELOG.md](mdc:CHANGELOG.md) to add an entry for the next release number and a list of changes since the last release from the output of `yarn changelog`. See the `Updating the Changelog` section in [publishing-a-release.md](mdc:docs/publishing-a-release.md) for more details. Do not remove any changelog entries.
20
24
6. Commit the changes to [CHANGELOG.md](mdc:CHANGELOG.md) with `meta(changelog): Update changelog for VERSION` where `VERSION` is the version of the release, e.g. `meta(changelog): Update changelog for 8.1.0`
21
25
7. Push the `prepare-release/VERSION` branch to origin and remind the user that the release PR needs to be opened from the `master` branch.
26
+
8. In case you were working on a different branch, you can checkout back to the branch you were working on and continue your work by unstashing the changes you stashed earlier with the command `git stash pop` (only if you stashed changes).
0 commit comments