* RFA: gold version number
@ 2016-03-25 0:10 Cary Coutant
2016-03-25 5:07 ` Ian Lance Taylor
2016-03-27 17:59 ` Matt Rice
0 siblings, 2 replies; 6+ messages in thread
From: Cary Coutant @ 2016-03-25 0:10 UTC (permalink / raw)
To: Ian Lance Taylor, Nick Clifton, Alan Modra; +Cc: Binutils
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?
-cary
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFA: gold version number
2016-03-25 0:10 RFA: gold version number Cary Coutant
@ 2016-03-25 5:07 ` Ian Lance Taylor
2016-03-25 10:58 ` Tristan Gingold
2016-03-28 22:26 ` Mike Frysinger
2016-03-27 17:59 ` Matt Rice
1 sibling, 2 replies; 6+ messages in thread
From: Ian Lance Taylor @ 2016-03-25 5:07 UTC (permalink / raw)
To: Cary Coutant; +Cc: Nick Clifton, Alan Modra, Binutils
On Thu, Mar 24, 2016 at 5:10 PM, Cary Coutant <ccoutant@gmail.com> 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.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFA: gold version number
2016-03-25 5:07 ` Ian Lance Taylor
@ 2016-03-25 10:58 ` Tristan Gingold
2016-03-28 22:26 ` Mike Frysinger
1 sibling, 0 replies; 6+ messages in thread
From: Tristan Gingold @ 2016-03-25 10:58 UTC (permalink / raw)
To: Ian Lance Taylor, Cary Coutant; +Cc: Nick Clifton, Alan Modra, Binutils
> On 25 Mar 2016, at 06:07, Ian Lance Taylor <iant@google.com> wrote:
>
> On Thu, Mar 24, 2016 at 5:10 PM, Cary Coutant <ccoutant@gmail.com> 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.
Doable.
But it would be simpler if gold were using bfd/version.m4
Tristan.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFA: gold version number
2016-03-25 0:10 RFA: gold version number Cary Coutant
2016-03-25 5:07 ` Ian Lance Taylor
@ 2016-03-27 17:59 ` Matt Rice
1 sibling, 0 replies; 6+ messages in thread
From: Matt Rice @ 2016-03-27 17:59 UTC (permalink / raw)
To: Cary Coutant; +Cc: Ian Lance Taylor, Nick Clifton, Alan Modra, Binutils
On Thu, Mar 24, 2016 at 5:10 PM, Cary Coutant <ccoutant@gmail.com> 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?
its worth noting that gnulib contains a git-version-gen module:
https://www.gnu.org/software/gnulib/MODULES.html#module=git-version-gen
bison uses it for example in AC_INIT on line 27 currently...
http://git.savannah.gnu.org/cgit/bison.git/tree/configure.ac
AC_INIT([GNU Bison],
m4_esyscmd([build-aux/git-version-gen .tarball-version]),
[bug-bison@gnu.org])
where m4_esyscmd() iirc runs at autoreconf time
generating these from the makefile/autoconf is the generally recommended way
e.g. that's how the kernel does it with it's GIT-VERSION-GEN script
however things such as bison's usage of it has caused issues with
distributions that use git as the source package format particularly
in these kinds of development tools that appear early in the
dependency graph, where you can assume that git appears on the
developers machine, but not necessarily on the build machine as they
may just be using the file system resulting from some git checkout...
so it is increasing the needed initial bootstrap image
it may be possible to do so from git hooks using something like a git
smudge/clean filter
http://gilesbowkett.blogspot.com/2013/05/how-gits-smudge-and-clean-filters-work.html
https://git-scm.com/docs/gitattributes
that would work with the above case but goes somewhat off the beaten
path, i'm not sure how well any of the above work with the project
within a project with distinct versioning situation though..
BFD_VERSION_DATE=$(date +"%Y%m%d" --date="@$(git log --pretty=format:"%ct" -1)")
SHA1=$(git rev-parse HEAD)
git describe $SHA1
git tag --points-at $SHA1 | tac | head -n 1
hope that is helpful...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFA: gold version number
2016-03-25 5:07 ` Ian Lance Taylor
2016-03-25 10:58 ` Tristan Gingold
@ 2016-03-28 22:26 ` Mike Frysinger
2016-03-28 22:34 ` Cary Coutant
1 sibling, 1 reply; 6+ messages in thread
From: Mike Frysinger @ 2016-03-28 22:26 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Cary Coutant, Nick Clifton, Alan Modra, Binutils
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFA: gold version number
2016-03-28 22:26 ` Mike Frysinger
@ 2016-03-28 22:34 ` Cary Coutant
0 siblings, 0 replies; 6+ messages in thread
From: Cary Coutant @ 2016-03-28 22:34 UTC (permalink / raw)
To: Ian Lance Taylor, Cary Coutant, Nick Clifton, Alan Modra, Binutils
>> 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 ...
OK, I can go with that. I probably should have bumped it for s390 and
MIPS-64 support. (Maybe it's not too late to do it for MIPS-64, as the
last patches for that are still about to land.)
The plugin API has its own version number; it reports the linker
version number only for logging/diagnostic purposes. (Plus, it was
designed so as to rarely need a version number change. New features
are added simply by allocating new LDPT values, keeping all existing
ones exactly the same as before, kind of like Unix system call
numbers.)
Thanks for the advice!
-cary
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-28 22:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-25 0:10 RFA: gold version number Cary Coutant
2016-03-25 5:07 ` Ian Lance Taylor
2016-03-25 10:58 ` Tristan Gingold
2016-03-28 22:26 ` Mike Frysinger
2016-03-28 22:34 ` Cary Coutant
2016-03-27 17:59 ` Matt Rice
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).