@@ -173,66 +173,19 @@ So our release branch and model must be flexible enough to solve it via cherry p
173173
174174### Changelog, Release Note, Release Announcement Blog
175175
176- Each release in testnet and mainnet must have corresponding release note, changelog , and announcement blog
176+ Each release in testnet and mainnet must have corresponding changelog, release note, and announcement blog
177177
178- - Changelog
178+ - Changelog and release notes
179179 - lives in the repo ` /CHANGELOG ` dir
180- - exact commit history diff from last release
180+ - release note: high level summary of key changes users need to be aware of
181+ - changelog: exact commit history diff from last release
181182 - See examples in Kubernetes https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG
182- - Release note:
183- - lives in the repo as part of release description under β[ Releases] ( https://github.com/Layr-Labs/eigenlayer-contracts/releases ) β
184- - high level summary of key changes users need to be aware of
185- - See template below
186- - Owner: release manager and PM
187183- Release announcement blog
188184 - published to [ blog.eigenlayer.xyz] ( http://blog.eigenlayer.xyz )
189185 - an announcement with polished language to introduce the release to users. It will include content in both release notes and changelog
190186 - See examples in Golang https://tip.golang.org/doc/go1.24
191187 - Owner: release manager and PM
192188
193- Release Note must follow template:
194-
195- ``` jsx
196- < release- version>
197-
198- π New Features β Highlight major new functionality.
199- - ...
200- - ...
201-
202- β Breaking Changes β Call out backward- incompatible changes.
203- - ...
204- - ...
205-
206- π Deprecations β Mention features that are being phased out.
207- - ...
208- - ...
209-
210- π οΈ Security Fixes β Specify patched vulnerabilities.
211- - ...
212- - ...
213-
214- π§ Improvements β Enhancements to existing features.
215- - ...
216- - ...
217-
218- π Bug Fixes β List resolved issues.
219- - ...
220- - ...
221- ```
222-
223- When writing ** release notes** and ** changelog entries** , follow these best practices to ensure clarity, usefulness, and professionalism.
224-
225- ** Required Best Practices**
226-
227- 1 . ** Be Clear and Concise** β Use simple, direct language. Avoid jargon unless necessary.
228- 2 . ** Categorize Changes** β Use standard sectioned template above.
229- 3 . ** Provide Context** β Briefly explain why the change was made, not just what changed.
230- 4 . ** Use a Consistent Format** β Follow a structured template for every release.
231- 5 . ** Include Relevant Links** β Link to issue trackers, PRs, or documentation for more details.
232- 6 . ** Highlight User Impact** β Mention how the update affects users and any required actions.
233- 7 . ** Keep It Versioned** β Use semantic versioning (e.g., ` v2.3.1 ` ) and list versions in descending order.
234- 8 . ** Avoid Internal-Only Details** β Don't include internal project discussions that arenβt relevant to users.
235- 9 . ** Maintain a Single Source of Truth** β Store changelogs in a ` CHANGELOG.md ` file or an equivalent documentation system.
236189
237190
238191## Release Manager Responsibilities
0 commit comments