On 01/07/15 15:59, wm4 wrote: > This returns something like "v12_dev0-1332-g333a27c". This is much more > useful than the individual library versions, of which there are too > many, and which are very hard to map back to releases or git commits. > --- > Don't forget the version bump. > --- > doc/APIchanges | 3 +++ > libavutil/avutil.h | 7 +++++++ > libavutil/utils.c | 6 ++++++ > 3 files changed, 16 insertions(+) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 5d39ec6..e309834 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -13,6 +13,9 @@ libavutil: 2014-08-09 > > API changes, most recent first: > > +2015-xx-xx - xxxxxxx - lavu 56.xx.0 > + Add avutil_version_info(). > + > 2015-xx-xx - xxxxxxx - lavc 56.23.0 > Add av_vda_default_init2. > > diff --git a/libavutil/avutil.h b/libavutil/avutil.h > index f056415..126f047 100644 > --- a/libavutil/avutil.h > +++ b/libavutil/avutil.h > @@ -164,6 +164,13 @@ > unsigned avutil_version(void); > > /** > + * Return an informative version string. This usually the actual release > version > + * number and a git hash. This string has no fixed format and can change any > + * time. It should never be parsed by code. > + */ > +const char *avutil_version_info(void); > + > +/** > * Return the libavutil build-time configuration. > */ > const char *avutil_configuration(void); > diff --git a/libavutil/utils.c b/libavutil/utils.c > index c8c161d..1b5acd5 100644 > --- a/libavutil/utils.c > +++ b/libavutil/utils.c > @@ -18,12 +18,18 @@ > > #include "config.h" > #include "avutil.h" > +#include "../version.h"
Probably the file can be moved to libavutil as well. Beside this nit I guess it is fine. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
