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
Received on Mon Jun 01 2015 - 21:12:46 CEST