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 Git hash is there; - the strictly increasing count from the N tag is there, Carl Eugen is happy; - 3.0dev417 means "on branch master, 417 commits since branch 3.0 was forked" (maybe a better syntax can be found), users who want an estimate of the relation between releases and Git snapshots are happy; - H20160303 is the approximate timestamp of the head commit (preferably the CommitDate rather than the AuthorDate), users who want to know how old is their version are happy. Also, we could have a parsing script in tools to translate that into human-readable information, and possibly fill in the blanks if it has access to a Git repository. Bonus point if a version of this script is available online as a CGI. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
