[FFmpeg-devel] [PATCH] Use git describe in version.sh
Ramiro Polla
ramiro.polla
Thu Dec 30 01:30:29 CET 2010
On Mon, Dec 27, 2010 at 7:37 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Mon, Dec 27, 2010 at 07:34:43PM +0100, Reinhard Tartler wrote:
>> 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,
IMO tagging after branching and having "0.7-12-githash" would be good.
>> 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
This leads to different revision numbers from the SVN repo because of
branches in SVN and interleaving libswscale history.
>> >> 2) Tag the commit immediately after branching for the next release and
>> >> ? ?tag as pre-0.7 for example.
I don't like this. Mainly because I get particularly annoyed when
people refer to a yet unreleased version of a program when using the
development branch (for example mentioning gcc 4.5.3 in bug reports).
>> >> 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.
This is assuming we don't have over 9999 revisions in a year =). But
tagging dates seems weird...
Other suggestions, anyone?
More information about the ffmpeg-devel
mailing list