On 6/21/10 Jun 21 -10:45 AM, dherring@... wrote:
> TCR wrote:
>> James Y Knight <foom@...> wrote:
>>> Could just use the git hash instead as a sub-release identifier, for
>> I quite like the structured version identifiers for they're so
>> much more human friendly in discussions. I usually use planet.sbcl to
>> read about context of a particular commit, as long as the commit
>> in question is reasonably recent which it most often is.
>> It's also easier to ask someone having a problem, "What version
>> are you running on?", and then you can usually quickly decide
>> whether or not that version is before or past a particular
>> commit you know of being problematic or crucial in some way
>> related to the description of the problem.
>> How do projects using the git hash deal with this?
> For me, once a project's SVN revision number has exceeded a couple digits,
> it becomes just as meaningless as a SHA1 hash. When somebody complains
> about an issue, and I remember fixing it roughly a hundred commits ago, I
> fire up gitk (do all my svn via git-svn) and search for my commit message
> and their revision number. It is then trivial to look through the history
> (which is usually better than my memory).
> Same goes for x.y.z version numbers. A date and quality modifier (e.g.
> alpha, beta, release) is a lot more natural.
FWIW, I find the exact opposite --- x.y.z is a lot more meaningful to me
than a hash since the z is monotonically increasing (within x.y). A SHA
hash doesn't instantly tell me when one thing is greater than another.