bfd/version.h: Add rationale for BFD_VERSION_DATE

bfd/ChangeLog:
2017-09-22  Pedro Alves  <palves@redhat.com>
	    Alan Modra  <amodra@gmail.com>

	* version.h: Add comment.

diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index ebefab38f5dca3b82fb8a5ccf27cfcca1471e879..46643eb31dac8237fb62d77c7645b8fbffb07383 100644 (file)
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,3 +1,8 @@
+2017-09-22  Pedro Alves  <palves@redhat.com>
+           Alan Modra  <amodra@gmail.com>
+
+       * version.h: Add comment.
+
 2017-09-21  Andreas Arnez  <arnez@linux.vnet.ibm.com>
 
        * elf.c (elfcore_grok_note): For the cases NT_S390_GS_CB and

diff --git a/bfd/version.h b/bfd/version.h
index 9e389e90389f8a1db183aecad6e87a23f0bc328a..162a820e8914da47e085609816152fc44b143e6f 100644 (file)
--- a/bfd/version.h
+++ b/bfd/version.h
@@ -1,3 +1,21 @@
+/* The date below is automatically updated every day by a bot.  During
+   development, we include the date in the tools' version strings
+   (visible in 'ld -v' etc.) because people build binutils from a
+   variety of sources - git, tarballs, distro sources - and we want
+   something that can easily identify the source they used when they
+   report bugs.  The bfd version plus date is usually good enough for
+   that purpose.
+
+   During development, this date ends up in libbfd and libopcodes
+   sonames because people naturally expect shared libraries with the
+   same soname to have compatible ABIs.  We could bump the bfd version
+   on every ABI change, but that's just another thing contributors and
+   maintainers would need to remember.  Instead, it's much easier for
+   all if the soname contains the date.  This is not perfect but is
+   good enough.
+
+   In releases, the date is not included in either version strings or
+   sonames.  */
 #define BFD_VERSION_DATE 20170922
 #define BFD_VERSION @bfd_version@
 #define BFD_VERSION_STRING  @bfd_version_package@ @bfd_version_string@