On Fri, Mar 04, 2016 at 08:46:42PM +0100, Reimar Döffinger wrote: > On 04.03.2016, at 11:24, Nicolas George <geo...@nsup.org> wrote: > > > 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.
I agree. > Particularly the branch name can easily be misleading as it can be anyone's > master, not necessarily the one on ffmpeg.org. Indeed. ----->8------ So after all the email exchanges, I think there are certain things that our version SHOULD contain: - The hash - The next release (i.e. n3.1) - A way to compare two versions The date is considered to be "good" but perhaps not as necessary. So here I propose the following for the master branch: n3.1-dev-N-78911-gf81c81c / | \ \ / | \ \ next distinguish commits since commit release from actual the start of hash release time For comparison, versions on the release branch are as follows: n3.0-4-geb46065 / | \ / \ \ previous commits since commit release that release hash A few reasons why I chose this style for master branch rather than some other: - I want it to bear some resemblance to our original style - which also happens to satisfy Carl's perhaps unjustified dependency on it - I want it to be somewhat consistent with our release branch version - It should also be gitrevisions(7)-compatible I would also like to raise an awareness of versioning when full Git metadata is not available. version.sh tries its best to get information, and usually ends up with one of the following circumstances. However, the format is wildly inconsistent, and I want to fix this once and for all. I can utilize the RELEASE file to provide information on our next release, even when tags are unavailable. : Current : New Master Full : N-78911-gf81c81c : n3.1-dev-N-78911-gf81c81c Shallow clone : git-2016-03-04-f81c81c : n3.1-dev-gf81c81c Gitweb tarball : 3.0.git-f81c81c : n3.1-dev-gf81c81c Nothing : 3.0.git : n3.1-dev Release branch Full : n3.0-4-geb46065 : n3.0.1-dev-4-geb46065 Shallow clone : eb46065 : n3.0.1-dev-geb56065 Nothing : 3.0 : n3.0.1-dev Release Full : n3.0 : n3.0 Shallow clone : n3.0 : n3.0 Nothing : 3.0 : n3.0 Any objections? Timothy _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel