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. 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
