Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 4 down vote favorite
3

A big part of my daily job is developing software for use on machines with different versions of the same software, like bash, find, and grep. When encountering a feature which would be useful for example to simplify code, it is important to know whether this feature is available in the oldest installed tools. For critical stuff, it would also be useful to know whether this feature was new or has existed for years in the oldest installed tools.

What are quick ways to answer this authoritatively for Linux tools, especially the GNU Core Utils? Some possibilities in order of decreasing accuracy:

  • Binary binary search (sic) by running the different versions is of course the ultimate answer, but is by far the most time consuming. Older installations are often not available for security reasons.
  • Reading the code is almost as good, but it can be prohibitively time consuming if the feature is vaguely named, the name doesn't correspond directly to variable/function/object names, or it was implemented before it was enabled.
  • Change logs, when available, usually connect feature changes to software versions.
  • Commit logs can provide hints, but do not know which version they will be included in.
  • man pages rarely mention dates.
  • The same applies to Googling, and you'd also have a hard time excluding all the non-authoritative sources.
share|improve this question
Could you perhaps elaborate on the reason(s) behind this question? – Faheem Mitha Mar 23 '11 at 9:00

2 Answers

up vote 6 down vote accepted

Generally, there's a changelog. In fact, this (or other "prominent notices" of changes) is required by the GPL! (At least, effectively so for anything with multiple contributors — see GPLv2 section 2a.)

For the GNU coreutils package — and for pretty much everything else from the GNU project directly — this file is definitely the first place to look, and should answer your question 95% of the time.

share|improve this answer
Do you have a reference to the coreutils change log? The newest I could find was from 2007. – l0b0 Mar 23 '11 at 9:37
2  
GNU Coreutils ChangeLog has not been updated since 2007. cvs.savannah.gnu.org/viewvc/coreutils/… You have to look at the git logs now. – Mikel Mar 23 '11 at 9:43
2  
It may be auto-generated from the git logs. There's a ChangeLog.bz2 in /usr/share/doc/coreutils-8.10 on my Fedora system, and the top entry is from 2011-02-04. Possible also that this is a RH fork — I'll check into that later today. – mattdm♦ Mar 23 '11 at 10:19
@mattdm: There's /usr/share/doc/coreutils/changelog.gz on Ubuntu - Thanks! Unfortunately it only goes back to 2008, which is too recent for some of the relevant tools. I guess it takes over where the last one ended, though. – l0b0 Mar 23 '11 at 10:24
3  
Here is the proof: git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING Scroll to line 131. – Shinnok Mar 23 '11 at 12:00
show 1 more comment
up vote 2 down vote

Why not use the source control afferent to X to search for feature Y? The source repo is the best way to indentify when a particular feature was introduced.

For coreutils you can head to http://git.savannah.gnu.org/cgit/coreutils.git and search for keywords related to Y in log messages or particular lines of code you identified as belonging to Y. You can do that on the web interface directly, or even better, clone the source repo to your station and search using git-bisect, git-blame and git-log --grep.

Then Use git-describe to find out tag is the closest to a specific commmit. Tags are used for version numbers mostly, thus it will give you the version that introduced the commit.

You can adapt the above method, depending on X and it's source control.

share|improve this answer
How would you identify which commit / line went into which version of the software? Also, Savannah search is badly broken - No results for strings which are obviously in the same log messages. – l0b0 Mar 23 '11 at 9:26
Use git-describe to find out tag is the closest to a specific commmit. Tags are used for version numbers mostly. As for Savannah being broken, you can't do much about it. Git clone the repository to your box and work your way using the git commands i described in the post. – Shinnok Mar 23 '11 at 11:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.