svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump

John Baldwin jhb at FreeBSD.org
Thu Aug 1 17:39:17 UTC 2019


On 7/31/19 8:13 PM, Ed Maste wrote:
> On Thu, 1 Aug 2019 at 12:51, Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net> wrote:
>>
>> That would be fine, the important thing is that the
>> r350505 gets listed in the file,
> 
> I don't see any reason that r350505 specifically should be in a
> release note - this is a minor clarification of an existing
> deprecation notice. It seems having an overall "deprecation notices"
> section in the release notes would make sense, but they should really
> persist from version to version. Should we add a top-level
> DEPRECATION_NOTICES file perhaps? Or tag deprecation notices with some
> sort of comment in the source so they can be found with a 'grep'
> during release preparation?

I think it would make sense to have "sections" in RELNOTES that mimic
the sections we have in the existing release notes (e.g. kernel vs
userland).  That is effectively what GDB does with a top level NEWS
file.  This approach would hopefully make it easier to translate this
file into the real release notes.  It also means that a given "note"
can evolve over time (e.g. it might start with "XYZ is deprecated" to
"XYZ is removed" if a deprecation note is added and merged and later it
is removed) rather than only having a running journal ala UPDATING.

On the question of whether we want a dedicated section just for
deprecation notices, I'm not sure.  Probably we can just stick with the
layout of our existing release notes?

-- 
John Baldwin


More information about the svn-src-head mailing list