Open Stack

Excerpts from Kirill Zaitsev's message of 2015-11-12 00:26:02 +0300:
> I’m setting up reno for murano repository and been testing and playing with it a bit and this question seems unclear to me.
> 
> So where should we put release notes for stable releases? Into respective branches or into master?

Thanks for posting this to the list, Kirill.

Reno looks at the branch and tag history to figure out where a note
belongs based on where it was committed. So you want to put notes files
in the branch for the version where the change is, and you want to
commit the release notes before you tag the release.

Typically that will mean a note going into master with a fix, and then
being carried over in the backport into the stable branch. That backport
step is the reason reno uses lots of little files instead of one big
file -- it eliminates the merge conflict on the backport.

The *build* for the release notes happens from master, but it scans all
of the branches you tell it to (that's what the "branch" argument to the
release-notes directive does). So from master, the release notes build
can scan all of the relevant branches and publish their current release
notes together in one place. This last bit is why we ended up needing
the file with the release-notes directive that doesn't specify a branch
name (causing it to scan the "current" branch, which for a patch under
test includes any release notes files).

The shorter answer: Put the release note as close to the code change
as possible. In the same commit as a bug fix, or in one of the
patches in the series implementing a complex feature. Then make
sure that commit is going into the right branch. Reno will then use
the git history to figure out how to build the release notes document.

Doug

> 
> -- 
> Kirill Zaitsev
> Murano team
> Software Engineer
> Mirantis, Inc