Skip to content

Commit 2ef16c7

Browse files
authored
Finish up #379: "Releasing" docs (#453)
* "Releasing" docs Signed-off-by: Jens Reinecke <[email protected]> * Feedback jonahgraham Signed-off-by: Jens Reinecke <[email protected]> --------- Signed-off-by: Jens Reinecke <[email protected]>
1 parent 716fca0 commit 2ef16c7

File tree

1 file changed

+53
-0
lines changed

1 file changed

+53
-0
lines changed

README.md

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -99,3 +99,56 @@ However, if you are writing tests and developing this module independently you c
9999
configurations in the launch.json with VS Code. For example, if you open a \*.spec.ts file in VS Code
100100
you can use the "Mocha Current File & launch Server" configuration to automatically launch the debug
101101
server in one debugged process and the test in another.
102+
103+
## Releasing
104+
105+
### Prepare a release with a Pull Request
106+
107+
- Check if security scans require dependency updates in [package.json](./package.json).
108+
See [here](https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/security/code-scanning).
109+
- Update [CHANGELOG.md](./CHANGELOG.md).
110+
- Make sure it contains a section with the new version at the top of the file.
111+
If individual commits after the last release already added a new section,
112+
then rename this section accordingly.
113+
- Review the commit history since the last release and add any user facing changes which
114+
haven't been added yet.
115+
- Add references to issues/PRs where possible. Use the format of previous releases.
116+
Putting the displayed issue number in backticks is important to avoid that a web
117+
frontend automatically adds links. For example if referencing an issue/PR outside
118+
this repository which has the same number like an issue in the`cdt-gdb-adapter`repository.
119+
- Prefix issues from the sibling project `cdt-gdb-vscode` with their name if a change was
120+
made in cdt-gd-adapter to resolve it.
121+
- Look out for (internal) API changes that may impact downstream variants as part of the commit history
122+
review. Such downstream variants may for example derive from classes like `GDBDebugSessionBase`.
123+
Expectation is though that such changes are identified and added already during individual PR reviews.
124+
Sometimes, it can be difficult to spot such changes that can come with refactoring.
125+
Consider to retrospectively update sections of previously released versions with API
126+
changes to warn late adopters.
127+
- Update the `version` entry in [package.json](./package.json) to the new version.
128+
If the release only introduces defect fixes without significant feature changes,
129+
then bump the third ("patch") version digit.
130+
Bump the second ("minor") version digit when new features have been added.
131+
Update the first ("major") version digit if there are changes that remove features
132+
or significantly change existing behavior.
133+
134+
### Start the publishing
135+
136+
After the PR has been reviewed and merged, go to the GitHub [releases page](https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/releases):
137+
138+
- Click `Draft a new release`.
139+
- Click the `Select Tag` dropdown and enter the new version in the form `vX.Y.Z`.
140+
- Click the `Generate release notes` button. This inserts a release name based on the
141+
selected tag. And creates a list of commits since the last release as release notes
142+
that are shown on GitHub.
143+
- Select whether the release is a pre-release and/or if it is the latest release to show
144+
on the GitHub repository page. Usually, no change of the defaults is required.
145+
- Click the `Publish release` button. This creates a new release and pushes the defined tag.
146+
The tag push triggers a GitHub action which builds, tests and finally uploads release
147+
artifacts. It may take a few minutes for this and the release's asset list to complete.
148+
149+
**Note**:
150+
151+
- If CI should fail before the GitHub asset upload, you can try to rerun the failing GitHub action/jobs.
152+
- If more fixing is needed, you unfortunately may need to again bump the version number and repeat the entire process.
153+
154+
**Important**: Making a CDT GDB Debug Adapter release requires you to be a [committer](https://www.eclipse.org/membership/become-a-member/committer/).

0 commit comments

Comments
 (0)