This is a request for proposals for processes and tools that make it easier for the OpenSearch community to understand changes to our repositories, both at release time, and in between releases. The objectives, tenants, and goals provided here will be used as our criteria for evaluating the different proposals.

Objective

The objective is to solve the entire collection of issues around generating both ongoing CHANGELOGs, and release notes during GA of the product, for all OpenSearch project repositories.

Tenets

• Changelogs are for users [1], not project contributors nor machines. Not every commit is relevant to a user so not all commits are in the changelog.
• Changelog entries are peer reviewed and approved like any other part of a contribution.
• Changelogs list all significant unreleased changes.
• Changelog entries are editable after initial commit.
• Changelogs minimize maintainer work, are adopted
• Changelogs are trustworthy and up-to-date.

[1] Users are defined as operators/administrators, developers integrating with SDKs, and end-users interacting with UIs or REST APIs.

Goals

• Preparing release notes from any maintained branch at any time should be trivial and quick (< 1 hour).
• The content of the changelog at the time of release is exactly what goes into the component level release notes. This doesn’t include a “release highlights” or similar summary that may be included in any particular release.
• The changelog is transparent to the versioning / branching strategy, i.e. if a commit that introduces a changelog entry is merged into a branch for a particular release, then the changelog entry goes to the right place with minimal or no additional effort.
• Existing backporting automation should be unaffected.
• The contributor experience should be improved, not degraded.

Scope

• Tenets and goals apply to all OpenSearch project repositories
  • We’d like a generalized solution to CHANGELOGs and release notes that can be applied to any repository in the organization.
  • Individual repository owners are free to experiment, and may choose a different solution or approach, as long as it satisfies the goals above.
• Working outside of GitHub/Jenkins is not required

Proposal Process

1. Submit proposals via the proposal issue template or as a PR in this repository by April 13, 2023
2. Link your proposal issue or PR to this issue via a comment here. This discussion thread here will be for clarification questions and updates on the overall proposal progress.
3. Review linked proposals and comment on them directly.