[FFmpeg-devel] [PATCH] Use git describe in version.sh

[Reinhard Tartler]

On Mon, Dec 27, 2010 at 18:10:36 (CET), Michael Niedermayer wrote:

> On Wed, Dec 15, 2010 at 11:18:45AM +0100, Janne Grunau wrote:
>> On Wed, Dec 15, 2010 at 12:45:18AM -0200, Ramiro Polla wrote:
>> > Hi,
>> > 
>> > Attached patch makes version.sh use git describe for version string.
>> > Currently it will give the same result, since we have no tags in the
>> > git tree.
>> 
>> patch looks good
>> 
>> > And this brings another issue: I'd like for FFmpeg to still have some
>> > sort of monotonically increasing revision number when we switch to
>> > git. If we add tags to the tree, we'll get better version strings like
>> > "versionX-3-g9c2d982", where versionX is the tag name, 3 is the number
>> > of commits since the tag, and g9c2d982 the short git hash. We have to
>> > decide on what to tag though, since the releases are tagged after
>> > branching.
>> 
>> I would prefer tagging releases on master and branch afterwards but I don't
>> think we'll agree on that.
>
> IMO releases should use the revission number from where they where
> branched off in their revission identifer (like
> r12653-pre-0.7-githash) not devel HEAD using release
> versions+something but rather (r12653-githash)

That scheme doesn't look very "git-ish". It is probably very non-trivial
to implement and is likely to confuse people familar to the version
tagging conventions of other projects that use git.

Ideally, that policy would also cover private developer branches, so
that binaries built from a branch 'ffmpeg-michael.git' or
'ffmpeg-mt.git' are easy to identify. This information probably needs
some level of configuration in the version.sh script.

For releases, how about something like "0.7-12-githash", where "0.7"
stands for branchpoint for the 0.7 release, and "12" indicates twelve
additional commits from there. To avoid confusion, we name the first
'real' release then "0.7.0", such that real releases always end up with
three parts in the version number.

For developer branches, an identification like "mt-0.7-377-githash"
could then indicate 377 commits after the 0.7 branchpoint from the "mt"
branch.

>> That leaves 3 options:
>> 
>> 1) Tag the root commit and have something like svn rev numbers
>> 2) Tag the commit immediately after branching for the next release and
>>    tag as pre-0.7 for example.
>> 3) Tag at specific date, we could for example tag the first commit of a
>>    year as 2011 and have increasing numbers from that.
>> 
>> I like 3) since it already gives an approximate age of the version and
>> keeps the monotonically increasing number limited to 4 digits which is
>> easier to remember than 5/6 digit numbers like the svn revisions.
>
> If you want something easier to remember try using more than 10 chars
> with lower case letters and numbers you can fit 46k revissions in 3 chars
> and 4 should be enough until we switch vcs again

TBH, I don't see how this leads to version identifiers that are easy to
memorize.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4