[openstack-dev] [release] using reno for libraries

Dmitry Tantsur dtantsur at redhat.com
Mon Nov 30 09:06:25 UTC 2015


On 11/28/2015 02:48 PM, Doug Hellmann wrote:
> 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.

This looks like unnecessary overcomplication. Why not use such a 
convenient tool for both kinds of release notes instead of having us 
invent and maintain one more place to put release notes, now for 
developers? It's already not so easy to explain reno to newcomers, this 
idea makes it even harder...

>
> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




More information about the OpenStack-dev mailing list