Open Stack

Excerpts from Doug Hellmann's message of 2015-11-27 10:21:36 -0500:
> Liaisons,
> 
> We're making good progress on adding reno to service projects as
> we head to the Mitaka-1 milestone. Thank you!
> 
> We also need to add reno to all of the other deliverables with
> changes that might affect deployers. That means clients and other
> libraries, SDKs, etc. with configuration options or where releases
> can change deployment behavior in some way. Now that most teams
> have been through this conversion once, it should be easy to replicate
> for the other repositories in a similar way.
> 
> Libraries have 2 audiences for release notes: developers consuming
> the library and deployers pushing out new versions of the libraries.
> To separate the notes for the two audiences, and avoid doing manually
> something that we have been doing automatically, we can use reno
> just for deployer release notes (changes in support for options,
> drivers, etc.). That means the library repositories that need reno
> should have it configured just like for the service projects, with
> the separate jobs and a publishing location different from their
> existing developer documentation. The developer docs can continue
> to include notes for the developer audience.

I've had a couple of questions about this split for release notes. The
intent is for developer-focused notes to continue to come from commit
messages and in-tree documentation, while using reno for new and
additional deployer-focused communication. Most commits to libraries
won't need reno release notes.

Doug

> 
> After we start using reno for libraries, the release announcement
> email tool will be updated to use those same notes to build the
> message in addition to looking at the git change log. This will be
> a big step toward unifying the release process for services and
> libraries, and will allow us to make progress on completing the
> automation work we have planned for this cycle.
> 
> It's not necessary to add reno to the liberty branch for library
> projects, since we tend to backport far fewer changes to libraries.
> If you maintain a library that does see a lot of backports, by all
> means go ahead and add reno, but it's not a requirement. If you do
> set up multiple branches, make sure you have one page that uses the
> release-notes directive without specifing a branch, as in the
> oslo.config example, to build notes for the "current" branch to get
> releases from master and to serve as a test for rendering notes
> added to stable branches.
> 
> Thanks,
> Doug
>