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