[FFmpeg-devel] [PATCH] Use git describe in version.sh
Mon Dec 27 20:37:23 CET 2010
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
> 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"
> >> 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
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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel