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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Mar 4 20:46:42 CET 2016


On 04.03.2016, at 11:24, Nicolas George <george at nsup.org> wrote:

> 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 formatting is rather ugly but I'd be in favour of something like that.
An attempt to order the information in increasing detail might be:
v3.0+417-D20160303-N78879-g510046c
Note that I'm not convinced the git describe info/branch info/number of commits since release is all that useful, but the base release version number seems nice to have.
Particularly the branch name can easily be misleading as it can be anyone's master, not necessarily the one on ffmpeg.org.


More information about the ffmpeg-devel mailing list