With https://github.com/elastic/elastic-otel-java we are used to publish release notes on github releases:
- users can subscribe to new releases and get notifications, they don't have to use other tools like renovate/dependabot/... updates to get notified, also they may not have other way to get this information in a timely manner.
- it's just convenient
- we can link to our docs, but this is one extra indirection
- if we use a link to our docs, when release is published, docs publication may take a few minutes, which means the first users of GH release may see a broken link (minor, but not great to inspire trust)
GH releases are created using a simple markdown, and we can hack the output of docs-builder bundle render to make it look rather acceptable, but this is brittle and will require maintenance.
For example with the following script wip.sh
#!/bin/bash
set -euo pipefail
tmp="$(mktemp -d)"
version="${1:-1.10.0}"
curl -q "https://raw.githubusercontent.com/elastic/elastic-otel-java/refs/heads/main/docs/releases/${version}.yaml" \
> "${tmp}/${version}.yaml"
docs-builder changelog render \
--input "${tmp}/${version}.yaml" \
--output "${tmp}"
echo ''
echo 'original:'
echo ''
cat "${tmp}/${version}/index.md" \
echo ''
echo 'modified:'
echo ''
cat "${tmp}/${version}/index.md" \
| sed -e "/## ${version} \[elastic-release-notes-${version}/d" \
| sed -e "/###/s/ \[elastic-${version}.*$//g"
Will produce the following output:
Raw output from render
## 1.10.0 [elastic-release-notes-1.10.0]
### Features and enhancements [elastic-1.10.0-features-enhancements]
* Update upstream OpenTelemetry agent dependencies to 2.26.1. [#1017](https://github.com/elastic/elastic-otel-java/pull/1017)
- javaagent:[2.26.1](https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/tag/v2.26.1) sdk:[1.60.1](https://github.com/open-telemetry/opentelemetry-java/releases/tag/v1.60.1) semconv:[1.40.0](https://github.com/open-telemetry/semantic-conventions-java/releases/tag/v1.40.0) contrib:[1.54.0](https://github.com/open-telemetry/opentelemetry-java-contrib/releases/tag/v1.54.0)
What we should have:
### Features and enhancements
* Update upstream OpenTelemetry agent dependencies to 2.26.1. [#1017](https://github.com/elastic/elastic-otel-java/pull/1017)
- javaagent:[2.26.1](https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/tag/v2.26.1) sdk:[1.60.1](https://github.com/open-telemetry/opentelemetry-java/releases/tag/v1.60.1) semconv:[1.40.0](https://github.com/open-telemetry/semantic-conventions-java/releases/tag/v1.40.0) contrib:[1.54.0](https://github.com/open-telemetry/opentelemetry-java-contrib/releases/tag/v1.54.0)
Related to this, some of our repositories are used to have a CHANGELOG.md at the root of the repository, it would also be nice to be able to use docs-builder changelog to maintain such files.
With those two use-cases in mind, maybe we should introduce a markdown-single dedicated format for rendering bundles in a single markdown file, both for a single version (for GH releases) and all of them (for the CHANGELOG.md).
Alternatively, providing extra options to customize the generated markdown like stripping content in headers and/or selecting the level range of the headers could also work here.
With https://github.com/elastic/elastic-otel-java we are used to publish release notes on github releases:
GH releases are created using a simple markdown, and we can hack the output of
docs-builder bundle renderto make it look rather acceptable, but this is brittle and will require maintenance.For example with the following script
wip.shWill produce the following output:
Raw output from render
What we should have:
Related to this, some of our repositories are used to have a
CHANGELOG.mdat the root of the repository, it would also be nice to be able to usedocs-builder changelogto maintain such files.With those two use-cases in mind, maybe we should introduce a
markdown-singlededicated format for rendering bundles in a single markdown file, both for a single version (for GH releases) and all of them (for theCHANGELOG.md).Alternatively, providing extra options to customize the generated markdown like stripping content in headers and/or selecting the level range of the headers could also work here.