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

[Thilo Borgmann]

Am 04.03.16 um 17:57 schrieb Timothy Gu:
> On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
>> Am 04.03.16 um 08:58 schrieb wm4:
>>>
>>> Being able to see the, well, version in the version output (instead of
>>> random numbers) sounds like a pretty convincing argument.
>>
>> 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?
> 
> It is continuous. But to the user's eye, N-71234 is no different from N-41234,
> and hence "random."

I assume that if there is no difference in the user's eye between
N-71234 and N-41234 then there is also no difference for that user
between dev-123 and dev-346.


>> 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?
> 
> However, you miss the point that the new system allows one to do the same.
> 
> In the old system:
> 
>     N-90001-gdeadbef
>     N-90000-gdeadbee
>     N-80000-gdeadbed
> 
> In the new system:
> 
>     v4.5-dev-123-gdeadbef
>     v4.5-dev-122-gdeadbee
>     v4.0-dev-45-gdeadbed
> 
> As you can see, they are functionally equivalent: you can immediately tell
> that they are in descending order with both systems.
> 
>> Assuming my thoughts are not based on void assumptions, I'm against removing the
>> N-tag from the version string.
> 
> I hope I have demonstrated that your concern is mistaken.

Except for the benefit of dev-123 tags you have. Thank you!


>> 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.
> 
> Can you elaborate on this? I am not sure I understand everything you are
> saying. Specfically, what is "devxy"?

The core concern about it is that is just redundant. I assume Timo to be
correct about:

"A new dev tag is made every time a release is branched off, to indicate
development of the next ffmpeg version started there, ..."

Then there is no gain of information in the dev-123 tag if there is
already the release number given. In that case "v4.5-gdeabdef" tells me
the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the
can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough.

Summing it all up for me, I think a release prefix would make perfect
sense. Thus, switching from

N-12345-abcdefg

to

v4.5-N-12345-abcdefg

should be done for the sake of the users. There is at least CE wanting
to stick with N-tags so why not? The only reason I can imagine for
getting rid of N-tags and/or including dev-123 tags would be that a
native git show command needs it to work properly as well as giving
better human readable information.

-Thilo