Re: [ft-devel] [ft] Another problem with X11 PCF fonts and 2.7.1, now with bisect

[Vincent Torri]

Hello

you can have a math formula to link the tarball version and the
libtool one, following what Johnny mentioned :

tarball version micro++ : bug fixes
tarball version minor++ : addition of API and micro set to 0
tarball version major++ : API and ABI break and micro and minor set to 0

then, here is what we use in our configure.ac's :


m4_define([v_maj], [1])
m4_define([v_min], [18])
m4_define([v_mic], [7])
m4_define([v_ver], [v_maj.v_min.v_mic])

m4_define([lt_cur], [m4_eval(v_maj + v_min)])
m4_define([lt_rev], [v_mic])
m4_define([lt_age], [v_min])

AC_INIT([project], [v_ver], [mail])

....

version_info="lt_cur:lt_rev:lt_age"
AC_SUBST([version_info])

and in our Makefile.am's :

project_la_LDFLAGS =  -version-info @version_info@

regards

Vincent Torri



On Fri, Jan 13, 2017 at 11:00 PM, Werner LEMBERG <address@hidden> wrote:
>
> Jonny,
>
>
>> Intentionally releasing new features (turning them ON by default) in
>> a patch release is unacceptable behaviour from any serious project.
>
> I underestimated the effect of the PCF change; the next version will
> have this feature off – I have already written that to the mailing
> list.  Maybe you've missed this.
>
>> Major number increase: New features that might break backwards
>>                        compatibility
>> Minor number increase: New features that DOESN'T break backwards
>>                        compatibility (thus new feature but turned
>>                        OFF default)
>> Micro/path number increase: Only bug fixes
>
> For me, `backwards compatibility' is something related to the ABI.  I
> have the feeling that you are mixing up software release numbers with
> DLL versions.  Have a look into `docs/VERSIONS.TXT'.
>
>> Even your news page states something in the line of "finally we have
>> a new 'minor' number increase so we can change default ..." (!)  No
>> really you can NOT do that in a minor version number bump, you do
>> that in a major number bump!
>
> Definitely not.  FreeType 3 would be a major redesign of the library
> coming with a new API.  In other words, new features are handled with
> the `minor' number in the source tarball.  Again: the versioning
> scheme of the tarball is *completely irrelevant* to the backwards
> compatibility of the ABI.
>
>> Your current ignorance to the versioning standard is not only
>> frustrating but directly causing major problems for distributions
>> and its users.
>
> Pfft.  You are greatly exaggerating.  You are the *first* one who
> brings up this complaint!
>
>> Please take some responsibility and comply with the standard or
>> ignore the versioning system and go with systemd-like versioning.
>
> It's not clear to me why the tone of your e-mail is so hostile.  Who
> are you in the software world to complain about `frustration' and
> `major problems for distributions and its users'?  Can you give some
> evidence for your claims?  And yes, I have read `semver.org' – since
> FreeType uses libtool, it relates to DLL versions and *not* to the
> tarball versions.
>
>
>     Werner
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel