////
Copyright (c) 2024 The C++ Alliance, Inc. (https://cppalliance.org)

Distributed under the Boost Software License, Version 1.0. (See accompanying
file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)

Official repository: https://github.com/boostorg/website-v2-docs
////
= Release Notes
:navtitle: Release Notes

Writing release notes is crucial for informing users about the changes made in the latest version of your library.

Two versions of your release notes need to be prepared: one for your library's own documentation, one for a Boost history that covers all libraries added or updated in a release. 

For the former, the Boost community does not have a strict format for your libraries' version of release notes (and some libraries refer to release notes as a  _change log_ or _history_). Follow the <<Checklist>>.

For the latter, you will need to update a Boost history file with a succinct version of your completed release notes. These files do have a specified format, described in <<_update_boost_history>>.

[square]
* <<Checklist>>
* <<Consistency and Formatting>>
* <<Release Note Macros>>
* <<Release Note Examples>>
* <<Update Boost History>>
* <<Best Practices>>
* <<See Also>>

== Checklist

When writing release notes for your library remember that the main goal is to effectively communicate the changes to the end-users. It's always a good practice to put yourself in the mind set of your developers, and think about what information they would need and appreciate. Be brief, but not so brief that only a seasoned user of your library will understand the context.

=== 1. Header Information

Make sure the version number, and date of release are mentioned.

=== 2. Summary

If this release addresses particular topics, provide a brief overview of the main changes, enhancements, or the theme of this release if there's one.

=== 3. Breaking Changes

Before detailing other updates, immediately inform users of any backward-incompatible changes. This is crucial as these changes can directly impact existing code. The process for breaking changes is covered in detail in  xref:version-control.adoc[].

=== 4. API Parameters

If you have added additional parameters (or changed a return value, or similar API change) to a function that are not breaking changes, then list them separately. If an API change might break an existing application, then ensure to list it under <<_breaking_changes>>.

=== 5. New Features

Describe any new features or major enhancements. For complex features, consider adding a brief example or pointing to updated documentation. If the feature is referenced in an *Issue*, then consider adding a link to that issue.

=== 6. Bug Fixes

List the fixed bugs, ideally with a brief description. If you're using a bug tracking system (like GitHub issues), provide links to the bug reports described in the issues. Include the identifier or number of the bug if available.

=== 7. Deprecations

Mention any functions, classes, or features that are deprecated and might be removed in future releases.

=== 8. Performance Improvements

Detail any optimizations or performance-related changes, ideally with metrics or benchmarks if they are significant.

=== 9. Documentation Updates

Highlight and link to any significant updates in documentation, new examples, or tutorials.

=== 10. Acknowledgements

Credit contributors or those who reported crucial bugs. Recognize any person or organization that played a special role in this release.

=== 11. Known Issues

Briefly describe any known limitations or issues that are still unresolved in the current release. Include known compatibility issues - including with compilers and tools, and other libraries.

=== 12. Upgrade Notes

Provide any specific instructions or recommendations for users upgrading from a previous version, especially if there are any manual steps involved.

== Consistency and Formatting

Use clear and concise language. Experience has shown that short release notes are read, long files much less so. Do not add into release notes extensive text that should be in your main library documentation.

* Be consistent in the formatting. If you're using bullet points for one section, maintain that for others.
* Use headers and sub-headers to clearly differentiate sections.
* Provide links to:
[circle]
    ** Your main library documentation, if there is updated text, examples or tutorials
    ** Relevant issues, discussions or threads

== Release Note Macros

Various macros are available to library authors and maintainers to help keep release notes consistent between libraries, and easier to both write and read. Absolute links _can_ be added to release notes, if necessary, though use of the following macros is encouraged and recommended.

[cols="1,3,1",options="header",stripes=even,frame=none]
|===
| *Macro* | *Description* | *Examples* 
| `boost_phrase:library[ <library name> , <library path>]` | Shows the library title in a consistent format, and links to the library on Git. | `boost_phrase:library[Asio,/libs/asio/]`, `boost_phrase:library[Beast,/libs/beast/]`, `boost_phrase:library[OpenMethod,/libs/openmethod]`
| `boost_at:<path to file>[ <title>]` | The specified "title" becomes a link to the file. | `Consult the boost_at:/doc/libs/1_90_0/doc/html/boost_asio/history.html[Revision History] for further details.`, `boost_at:/doc/libs/1_90_0/[Documentation]`
| `boost_gh:pr[ <library name>, <PR number]` | Provides a link to a GitHub PR for the specified library. | `Conform to std::pointer_traits requirements (boost_gh:pr[interprocess,32]).`, `boost_gh:pr[core,205]`
| `boost_gh:issue[<library name>, <ISSUE number>]` | Provides a link to the GitHub Issue for the specified library. | `Fixed named_condition_any fails to notify (boost_gh:issue[interprocess,62]).`
|===

== Release Note Examples

Checking out the release notes from fellow library authors and maintainers is good practice:

* https://github.com/boostorg/website-v2-docs/blob/develop/release-notes/boost_1_90_0.adoc[Boost 1.90 Release Notes]


== Update Boost History

When you have completed the library release notes, add the required information to the `[section New Libraries]` or `[section Updated Libraries]` of the https://github.com/boostorg/website/tree/master/feed/history[Boostorg History]. Copy the formatting of the examples below, which for reference is https://www.boost.org/doc/libs/latest/doc/html/quickbook.html[Quickbook format].

The examples below come from the https://github.com/boostorg/website/blob/master/feed/history/boost_1_83_0.qbk[boost_1_83_0.qbk] file:

[source,bash]
----
[section New Libraries]

[/ Example:
* [phrase library..[@/libs/accumulators/ Accumulators]:] Framework for
  incremental calculation, and collection of statistical accumulators, from Eric Niebler.
]

* [phrase library..[@/libs/compat/ Compat]:] A repository of C++11 implementations of
  standard components added in later C++ standards, from Peter Dimov and contributors.

[endsect]

[section Updated Libraries]

[/ Example:
* [phrase library..[@/libs/interprocess/ Interprocess]:]
  * Added anonymous shared memory for UNIX systems.
  * Move semantics for shared objects ([ticket 1932]).
  * Conform to `std::pointer_traits` requirements ([github_pr interprocess 32])
  * Fixed `named_condition_any` fails to notify ([github interprocess 62])
]

* [phrase library..[@/libs/any/ Any]:]
  * New `boost::anys::unique_any` C++11 class - an alternative to
    `boost::any` (or to `std::any`) that does not require copy
    or move construction from the held type.
  * Ported documentation to Quickbook, Doxygen comments now used in code.

  ....

  [endsect]
----

Note:: The macros used in Quickbook format for the history sections differ in detail from the macros available for the Release Notes.

== Best Practices

Experience has shown the following layout works well when writing release notes and having your users actually read them.

The first three (or less) bullet points should briefly explain the most impactful changes to your library. If new functionality has been added, this is the place for it.

The next bullet points, at most seven, but perhaps five is better, contain concise changes that affect the use of your library. This will include functions that have been improved, functions removed or deprecated, and other pertinent changes say to an API's parameters, errors, return values and similar.

If documentation has been updated, comments cleaned up, examples improved or removed, a single bullet point describing this has occurred is enough.

The rule of thumb here is to *keep the number of bullet points to ten or less*, as adding more is a good way of ensuring your users will skip or skim your release notes - a classic example of information "hiding in plain sight"!

== See Also

* https://github.com/boostorg/website/tree/master/feed/history[Boostorg History]
* xref:release-process.adoc[]
* xref:version-control.adoc[]


