@@ -99,3 +99,56 @@ However, if you are writing tests and developing this module independently you c
9999configurations in the launch.json with VS Code. For example, if you open a \* .spec.ts file in VS Code
100100you can use the " Mocha Current File & launch Server" configuration to automatically launch the debug
101101server 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