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