[FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Nicolas George]

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
"g510046c:N78879-3.0master417-H20160303":

- the Git hash is there;

- the strictly increasing count from the N tag is there, Carl Eugen is
  happy;

- 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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160304/c78ec008/attachment.sig>