Release Notes

Unreleased

2.3.2

Bug Fixes

  • Correct a problem with handling deleted release notes that triggered a TypeError with a message like “Can’t mix strings and bytes in path components”

2.3.1

Other Notes

  • The oslosphinx dependency for building documentation is now optional. This breaks a build cycle between oslosphinx and reno.

2.3.0

New Features

  • Add a lint command for checking the contents and names of the release notes files against some basic validation rules.

Bug Fixes

  • Sphinx 1.6.1 now interprets error and warning log messages as reasons to abort the build when strict mode is enabled. This release changes the log level for some calls that weren’t really errors to begin with to avoid having Sphinx abort the build unnecessarily.

2.2.1

Bug Fixes

  • Fix a problem caused by failing to process multiple files with the same UID portion of the filename. Ignore existing cases as long as there is a corrective patch to remove them. Prevent new cases from being introduced. See https://bugs.launchpad.net/reno/+bug/1688042 for details.

2.2.0

New Features

  • Add a --no-show-source option to the report command to skip including the note reference file names and SHA information in comments in the output. This restores the previous format of the output for cases where it is meant to be read by people directly, not just converted to HTML.
  • Add a --title option to the report command.

2.1.2

Bug Fixes

  • Fixes a problem with the sphinx extension that caused it to produce an error if it had a list of versions to include that were not within the set that seemed to be on the branch because of the branch-base detection logic. Now if a list of versions is included, the scan always includes the full history.

2.1.1

Bug Fixes

  • Fix a problem with branch references so that it is now possible to use a local tracking branch name when the branch only exists on the ‘origin’ remote. For example, this allows references to ‘stable/ocata’ when there is no local branch with that name but there is an ‘origin/stable/ocata’ branch.

2.1.0

New Features

  • Add a configuration option branch_name_re to hold a regular expression for choosing “interesting” branches when trying to automatically detect how far back the scanner should look. The default is stable/.+, which works for the OpenStack practice of creating branches named after the stable series of releases.
  • Add a configuration option sections to hold the list of permitted section identifiers and corresponding display names. This also determines the order in which sections are collated.

  • Add the ability to specify regular expressions to a define a customised versioning scheme for release tags and pre-release tags.

    By default this change supports the current versioning scheme used by OpenStack.

    To customise, update the config.yaml file with the appropriate values. For example, for tags with versions like v1.0.0 and pre-release versions like v1.0.0rc1 the following could be added to config.yaml:

    release_tag_re: 'v\d\.\d\.\d(rc\d+)?'
pre_release_tag_re: '(?P<pre_release>rc\d+$)'
  • Include the local working copy when scanning the history of the current branch. Notes files must at least be staged to indicate that they will eventually be part of the history, but subsequent changes to the file do not need to also be staged to be seen.
  • The scanner for the “current” branch (usually master) now stops when it encounters the base of an earlier branch matching the branch_name_re config option. This results in less history appearing on the unreleased pages, while still actually showing the current series and any unreleased notes.
  • The report output now includes debugging details with the filename and sha for the version of the content used to indicate where the content is from to assist with debugging formatting or content issues.

Bug Fixes

  • Fixes the logic for determining how far back in history to look when scanning a given branch. Reno now looks for the base of the “previous” branch, as determined by looking at branches matching branch_name_re in lexical order. This may not work if branches are created using version numbers as their names.

2.0.2

Bug Fixes

  • Fix a problem with the way reno automatically detects the initial version in a branch that prevented it from including all of the notes associated with a release, especially if the branch was created at a pre-release version number. Bug #1652092

2.0.0

This release includes a significant rewrite of the internal logic of reno to access git data through the dulwich library instead of the git command line porcelain.

New Features

  • Reno now supports having a config.yaml file in your release notes directory. It will search for file in the directory specified by --rel-notes-dir and parse it. It will apply whatever options are valid for that particular command. If an option is not relevant to a particular sub-command, it will not attempt to apply them.
  • Explicitly allow reno to scan starting from a tag by specifying the tag where a branch name would otherwise be used.
  • Add logic to allow reno to detect a branch that has been marked as end-of-life using the OpenStack community’s process of tagging the HEAD of a stable/foo branch foo-eol before deleting the branch. This means that references to “stable/foo” are translated to “foo-eol” when the branch does not exist, and that Sphinx directives do not need to be manually updated.
  • Set the default value of the reporoot argument for all command line programs to “.” and make it an optional parameter.
  • Automatically stop scanning branches at the point where they diverge from master. This avoids having release notes from older versions, that appear on master before the branch, from showing up in the versions from the branch. This logic is only applied to branches created from master.
  • Add a new configuration option, stop_at_branch_base, to control whether or not the scanner stops looking for changes at the point where a branch diverges from master. The default is True, meaning that the scanner does stop. A false value means that versions that appear on master from a point earlier than when the branch was created will be included when scanning the branch for release notes.
  • Reno now supports to set through template attribute in config.yaml a custom template which will be used by reno new to create notes.
  • Reno now enables with reno new --edit to create a note and edit it with your editor (defined with EDITOR environment variable).

Mainline

2.3.2

Bug Fixes

  • Correct a problem with handling deleted release notes that triggered a TypeError with a message like “Can’t mix strings and bytes in path components”

Newton Series

1.9.0

New Features

  • Add logic to allow reno to detect a branch that has been marked as end-of-life using the OpenStack community’s process of tagging the HEAD of a stable/foo branch foo-eol before deleting the branch. This means that references to “stable/foo” are translated to “foo-eol” when the branch does not exist, and that Sphinx directives do not need to be manually updated.