On 04.03.2016, at 11:24, Nicolas George <geo...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
