[x264] Update to 0.148-20160924-86b7198 version

[Sérgio Basto]

On Seg, 2016-09-26 at 20:52 +0200, Nicolas Chauvet wrote:
> 2016-09-26 18:34 GMT+02:00 Sérgio Basto <sergio at serjux.com>:
> > 
> > On Seg, 2016-09-26 at 11:59 +0200, Nicolas Chauvet wrote:
> > > 
> > > 2016-09-24 5:39 GMT+02:00 Sérgio M. Basto <sergiomb at rpmfusion.org
> > > >:
> > > > 
> > > > 
> > > > commit 36ac6ae0d5cb72b37ba60a8dc69eae3b147e0935
> > > > Author: Sérgio M. Basto <sergio at serjux.com>
> > > > Date:   Sat Sep 24 04:31:21 2016 +0100
> > > > 
> > > >     Update to 0.148-20160924-86b7198 version
> > > >  %endif
> > 
> > --- a/x264.spec
> > +++ b/x264.spec
> > @@ -1,7 +1,7 @@
> > -# globals for x264-0.148-20160614-a5e06b9.tar.bz2
> > +# globals for x264-0.148-20160924-86b7198.tar.bz2
> >  %global api 148
> > -%global gitdate 20160614
> > -%global gitversion a5e06b9
> > +%global gitdate 20160924
> > +%global gitversion 86b7198
> >  %global snapshot %{gitdate}-%{gitversion}
> >  %global gver .%{gitdate}git%{gitversion}
> >  %global branch stable
> > @@ -29,8 +29,8 @@
> > 
> >  Summary: H264/AVC video streams encoder
> >  Name: x264
> > -Version: 0.%{api}
> > -Release: 11%{?gver}%{?_with_bootstrap:_bootstrap}%{?dist}
> > +Version: 0.%{api}%{?gver}
> > +Release: 1%{?_with_bootstrap:_bootstrap}%{?dist}
> > 
> > 
> > Version: 0.148.20160924git86b7198-1
> > 
> > vs live555  Version:    2016.07.19
> > 
> > Version 0.148 is useful, you suggest 0.148.2016.09.24.git86b7198-1
> > ? ,
> > also git hash is useful ... or like this 0.148.20160924.86b7198-1
> >  without git world ?
> > 
> > yeah I think version should be with date of the source and git
> > shortcommit : %{gitdate}.git%{shortcommit} this should be part of
> > version, if not, one day we are in 0.148-117 and counting, is like
> > rtmpdump.spec ! ,  the version almost stopped , so our version
> > should
> > include %{gitdate}.git%{shortcommit} .
> > 
> > This is approved ?
> No I'm sorry, I should have been more accurate.
> 
> Packaging guideline mandate that the snapshot date and/or git hash to
> be in the release field.
> for x264 the version is 0.148 as reported by the upstream version.sh
> script. we could add the X264_REV field, but I'm not sure if it's
> sorted, so it might not be relevant as a RPM Version field (as later
> version won't be higher).
> So basically I'm asking to revert back to the previous version -
> release scheme.

The X264_REV field is the counting number of the commits, but I prefer
use date because have more meaning. 
And what do you say about Version: 0.148.20160924-1.git86b7198 ? 

> Why I've mentioned live555 is because it's the same as x264 in the
> sense that SONAME is the same since few time already but previously
> there were no enforcement that the version installed at runtime is
> high enough.
> It is done by dropping a RPM macro in the live555-devel that is later
> re-used by packages using live555 (mainly vlc). Since this macro is
> used at build time, this enforce that the live555 version used at
> build time is the same at runtime (but it could be >= instead of ==).

I didn't understand this part ...

> I don't know why you thought it was important to change the version
> field in x264, but this seems a better approach.
 
Because when source change, version should change. The Release field is
to counting the rebuilds. Since in x264, version and api version is the
same thing and since api doesn't change a lot, we should change the
version, otherwise release number doesn't make much sense, we are in
the 11 release, also makes more sense make this change in rhel7 where
the counting of release was reset to 0, in my very personal counting I
had begin by 1, since is one counting, but since is bootstrap may make
sense 0, I dunno.

Doen't make more sense use x264-0.148.20160614-1.gita5e06b9.el7 as next
version of x264-0.148-0.20160614gita5e06b9_bootstrap.el7 [1]? 

  0.148.20160924-1.git86b7198.fc26 
  0.148.20160614-1.gita5e06b9.el7

[1] http://koji.rpmfusion.org/koji/packageinfo?packageID=272

BTW, I already tried change NamingGuidelines [2] in
post or pre releases [2], we have some cases of packages where version
almost not change but source change often, digging on my emails I found
yet another choice in [3] but 0.148.%{gitdate}-1.git%{shortcommit} is
my choice.

[2] https://fedoraproject.org/wiki/Packaging:Versioning#Post-Release_packages 

[3] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V5JB5CBMRRD32EOY3HYXGOGQROM2EYSE/


Thanks and best regards,
-- 
Sérgio M. B.