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

[Michael Niedermayer]

On Mon, Dec 27, 2010 at 07:34:43PM +0100, Reinhard Tartler wrote:
> 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

i cant comment on these, that said its just a suggestion


> and is likely to confuse people familar to the version
> tagging conventions of other projects that use git.

i honestly dont care and think this shouldnt be a factor in the decission
anyway.


> 
> 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.

I dont care at all how relese branches are named but i do NOT want release
nonsense to leak into the main development revissions
devel HEAD is not a continuation of the last release. The last release is a
possibly modified branch of devel HEAD.
Releases can be done of revissions long after they are pushed to the public,


> 
> 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.

6a7b is easier to memorize than 1617412 because its shorter

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101227/089dfc7e/attachment.pgp>