Closed
Description
Is your feature request related to a problem? Please describe
Improvement in release template for OpenSearch repository
Describe the solution you'd like
Suggestions based on my experience as OpenSearch release manager.
Generic
- There should be some rough timelines on when specific task needs to be started (and completed if other process is dependent on it).
Preparation
- Triaging and labeling issues for release should be done on recurring basis. Doing this as one time activity before release is error prone.
CI/CD
- Add step for incrementing the main next release version. Added here: Fixing bwcVersions and bwc builds OpenSearch#2430
- Add step for incrementing the next patch version. Added here: Bump the version to 1.3.1 OpenSearch#2509
Re(add) this repo to the (if not exist) [manifest](https://github.com/opensearch-project/opensearch-build/blob/main/manifests/1.3.0/).
This step is not applicable for OpenSearch engine as it being core repository.
Release
- As mentioned here, we can make use of tools like git-release-notes to get release notes in markdown.
- Remove the dependabot commits (feedback from @dblock @stockholmux ) from generated release notes.
Post Release
Create a release tag
can be removed as there is already automation in place to create those automatically.
Related: opensearch-project/OpenSearch#2257