Subject: Re: [boost] Reminder: Boost Master branch will close for the 1.65.0 release on Wednesday
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-08-01 23:20:04
On 8/1/2017 4:18 PM, Stefan Seefeld via Boost wrote:
> On 01.08.2017 15:21, Andrey Semashev via Boost wrote:
>> On 08/01/17 22:14, Daniel James via Boost wrote:
>>> On 1 August 2017 at 19:27, Stefan Seefeld via Boost
>>> <boost_at_[hidden]> wrote:
>>>> On 01.08.2017 05:12, Daniel James via Boost wrote:
>>>>> I can see other problems with a more distributed approach. We'd lose
>>>>> the ability to edit release notes, which we do on occasion, and pull
>>>>> requests also make it easier to track changes as someone has to
>>>>> approve them.
>>>> Why would anyone want to edit or even just approve release notes I
>>>> about a project I maintain ?
>>> Fix links, typos, markup etc. A lot of that is done by Akira Takahashi.
>> Multiple times we also had to add to release notes after the release
>> has been shipped. For example, add notes about critical problems and
>> links to patches.
> Yes, all of which can be done per project, if Boost would allow release
> notes to be stored in the project-specific repositories, and rendered
> from project-specific documentation, rather than all from a single
> monolithic place.
I agree with you that having some method for individual libraries/tools
to create their own release notes would be better than having a central
place where release notes are kept. But how would this be done and who
is going to do it ? If you were willing to propose a way for this to be
done and then write some code ( maybe Python ) to combine the release
notes for the individual libraries/tools into the final release notes
format for any given release, then your argument would have much more
traction. Also I suspect that the individual library/tool format for
release notes should allow for ongoing notes for each release rather
than a complete replacement of a previous release's release notes with a
new set of notes.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk