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

[Thilo Borgmann]

Am 04.03.16 um 22:50 schrieb Timothy Gu:
> On Fri, Mar 04, 2016 at 06:48:04PM +0100, Thilo Borgmann wrote:
>> 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.
> 
> That's not the point. ...

>From here I really can't follow you...

> The point is that there is something before the dev
> part, and that's what makes the difference.

Do you mean the absolute anchor point for dev-123 (completely:
v3.0-dev123) which leads to "from release 3.0 go 123 steps further"?
If so, yes, it is different to N-12345 which leads to "go 12345 steps".
In that case, I would still prefer "absolute position" above "anchor +
relative position".


> When I said "no different," I meant except the fact that N-71234 is obviously
> newer. The fact that it fails to convey any additional information is the
> issue we are trying to attack.

With what I'm absolutely fine - I would like to see the release tag in
front. To determine how far away the build is from that release, I would
still prefer the absolute number (like said above).
Why? If I understand this correctly, the dev-123 tag version has a
certain disadvantage against N-tags.
Let's say there is v3.0-dev123.
Let's say there is v3.5-dev3.
Let's assume v3.5 was released right after 3.0 (3.1, 3.2, etc are not
existing)
Now, the question of interest is, how big is the difference between
v3.0-dev123 and v3.5-dev3?
This is the question this is all about, isn't it?
Since I do not know, how many commits there were at all for version 3.0,
I cannot answer the question. Maybe v3.0-dev142 was the last? Maybe
v3.0-dev897?
Let's assume there is v3.0-N-12345 and v3.5-N-12389... I can tell you
and estimate whatever 44 commits are worth estimating, no matter which
commit exactly raised version minor from 0 to 5.

But maybe I'm totally off-minded here.


>>>> 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.
> 
> I see where you are coming from. I will address this issue in my reply to
> Reimar.

Eh... No - I don't understand. Maybe your reply to Raimar will explain...

-Thilo