RFA: gold version number

[Mike Frysinger]

On 24 Mar 2016 22:07, Ian Lance Taylor wrote:
> On Thu, Mar 24, 2016 at 5:10 PM, Cary Coutant wrote:
> > I've been neglecting gold's version number, which has been stuck at
> > 1.11 for ages. I don't really have significant changes anymore that
> > would trigger an obvious version number bump, but a
> > consistently-incremented version number would still be useful for
> > tracking purposes. I suppose I could just remove it and show only the
> > binutils version number, but I think it's probably better to keep a
> > version number of its own.
> >
> > But what strategy should I use for incrementing it? I've thought about
> > bumping it just before each binutils release branch is cut, or perhaps
> > just after, but I'm not sure how to remind myself to do that at the
> > right moment.
> >
> > How should the version number distinguish between a release branch
> > build and a trunk build? Are there any hooks built in to git or
> > automake that would allow commit ids or datestamps to be included
> > automatically in the version string?
> >
> > Any advice?
> 
> I don't have any advice about automatic updates.  There must be some
> sort of binutils release checklist.
> 
> My general feeling is that the version number should change when there
> is a significant change in functionality, or when the plugin API
> changes in some way.  But it's also OK to use it for tracking, of
> course.

this is what i'd tend to leans towards as well.  for anyone who needs to
check the version to determine compatibility, i'd generally expect them
to look at the binutils version anyways ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20160328/dc8fd342/attachment.sig>