[FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
george at nsup.org
Fri Mar 4 11:24:31 CET 2016
Le quintidi 15 ventôse, an CCXXIV, Thilo Borgmann a écrit :
> Neither a good play on words nor elaborative; not even helpful.
> You say they are random numbers, CE says it is continuous. What is correct?
> Let's assume the N-tag is not random, then it is a useful extension of the
> pinpointing short hash, since the hashes are not relative to each other (so to
> speak random for the human eye) and therefore the N-tags are useful for
> determining if the user is ahead or behind a certain commit. According to what
> CE says, this helps for user support, Not? And if not, why would someone
> spending most of the time helping users think otherwise?
> Assuming my thoughts are not based on void assumptions, I'm against removing the
> N-tag from the version string.
> So what about the release tag? Well it is a quite useful extension because of
> the already mentioned possibility of determining the existing features at once.
> I'm pro adding it to the version string.
> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
> uselessly redundant to the existing hash tag in my eyes. Why add another more
> roughly estimation of the users repo-state? I don't think this should be added
> to the version string.
Replying here but not specifically to this mail.
We do not have to choose: there is no hard limit to the amount of
information that can be encoded in the version, the version string can be
arbitrarily long, as long as it is convenient.
The Git (short) hash carries all the information by itself, so it should be
present. But extra, redundant, information can be added for the convenience
of users and "supporters".
Basically, the version could be something like
- the Git hash is there;
- the strictly increasing count from the N tag is there, Carl Eugen is
- 3.0dev417 means "on branch master, 417 commits since branch 3.0 was
forked" (maybe a better syntax can be found), users who want an estimate
of the relation between releases and Git snapshots are happy;
- H20160303 is the approximate timestamp of the head commit (preferably the
CommitDate rather than the AuthorDate), users who want to know how old is
their version are happy.
Also, we could have a parsing script in tools to translate that into
human-readable information, and possibly fill in the blanks if it has access
to a Git repository. Bonus point if a version of this script is available
online as a CGI.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel