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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
