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
