Closed antifuchs closed 10 years ago
This looks useful, although I have one major reservation, which is for including Git commit hashes in the pkg version. OS X installer in most cases happily install whatever version you tell it to, but some people use software management systems to install OS X installer packages and rely on the pkg versions to determine what's newer. With a Git hash as part of the version string, 1.2.3_fedcba
could be an older package than 1.2.3_abcdef
but it would evaluate to being a higher version, and possibly not install.
This does make sense to me to have for formulae with explicit revision
numbers, though I haven't yet seen one that is higher than 1
? I wasn't able to find wiki documentation on what exactly this number would represent...
Hum, putting git commit SHA1 into version strings it not the intention behind this at all.
I'm not completely clear on how revisions work, either (there are no docs that I could find), but I believe they can be arbitrary numbers and have never observed a formula's revision being a git SHA1.
I think I was wrong in how I was interpreting my results of a test case. I tried the neko
formula:
But only now do I realize the Git hash is also right in the version string.
But gpsbabel
, which specifies an SVN rev:
https://github.com/Homebrew/homebrew/blob/0584e5aad9a7494d5d490aa6120bd5a20dfd270c/Library/Formula/gpsbabel.rb
Still builds a pkg with version 1.5.0
. So, I think this looks good.
Absent any helper methods, I think this is about right - if you want to split this out into something that's easier to read, I can think of a few refactorings that would probably help (: