On Mon, Jun 1, 2015, at 02:36 PM, Eric Pruitt wrote: > On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote: > > I don't know git well, just the basics, but why don't you use a git > > commit id as the target for patching and packaging? As far as I > > understand, a tag is just a "friendly" name for a commit id anyway. > > If $APPLICATION versions 4541b821941a65e9c220acec2ab7256d7b21d690 and up > support features X, Y and Z, can you tell me whether or not version > 02e09b181db9b55d93a43a943d49048a4aeb0364 also has those features?
Based on only the git commit id, the answer is no, and traditional version numbers are generally easier to compare; I see your point. But with access to the git log, then the answer is yes. Also, each git commit has a time-stamp (AFAIK). So the timestamp might be a way to express the version number, for example 2015.06.01.15.00.29 (year.month.day.hours.minutes.seconds in UTC), in a packaging system that expects a traditional version number. These could be compared like traditional version numbers. > This > become even more of a nuisance when you only have immediate access to a > compiled binary; I often build packages on one machine then distribute > only the binaries. Using hashes for versioning means you can't > $APPLICATION -V to easily figure out how old the binary is I'm using. I see your point. One way to resolve this problem is to have the -V option display the git commit id and timestamp. Just to clarify, I'm not saying that using the git commit id and/or timestamp is better than or as good as a traditional version number. What I'm saying is that, given an upstream that doesn't tag versions often enough for your liking, using the git commit id and/or timestamp seems like a workable solution. -- http://www.fastmail.com - Does exactly what it says on the tin
