Re: [ITP] znc 1.6.0

[Alexey Sokolov <alexey+cygwin at asokolov dot org>]

>> Well, in that case 1.6 works fine. When 1.7.0 will be released, the
>> filename will be changed to cygznc-1.7.dll.
> 
> No, hang on.  The reason for the version-independent number is to allow
> keeping the number the same for multiple versions of the package, and
> only bump it when an ABI breakage occurs.  Consider this scenario with
> different versioning schemes:
> 
>   znc 1.6
> 
>   --> cygznc1.dll  or  cygznc-1.6.dll
> 
>   znc 1.7 introduces new function znc_foo.  Adding functions is no ABI
>   breakage.
> 
>   --> cygznc1.dll  or  cygznc-1.6.dll
> 
>   znc 1.8 removes function znc_bar.  ABI breakage; existing modules
>   using this functions wouldn't load anymore.
> 
>   --> cygznc2.dll  or  cygznc-1.8.dll
> 
>   znc 1.9 adds function znc_foobar and a new structure.  No ABI breakage.
> 
>   --> cygznc2.dll  or  cygznc-1.8.dll
> 
>   znc 2.0 changes parameters to function znc_baz.  ABI breakage since
>   existing modules using this function may crash.
> 
>   --> cygznc3.dll  or  cygznc-2.0.dll
> 
> The first scheme is what most autoconf-based build systems use.
> However, openssl, for instance, uses the second scheme.  Both is ok, but
> in both schemes the ABI version number attached to the DLL name does not
> necessarily reflect the actual version number of the base package.  Did
> I explain it sufficiently?

ZNC 1.6.0
--> cygznc-1.6.dll (or cygznc1.6.dll)

ZNC 1.6.1 introduces new function znc_foo, no ABI breakage.
--> cygznc-1.6.dll

ZNC 1.6.2 introduces a new structure and a new function which uses it.
No ABI breakage.
--> cygznc-1.6.dll

ZNC 1.7.0 adds new virtual function to an existing class. Even if API
is not broken, ABI is broken.
--> cygznc-1.7.dll

ZNC 1.7.1 changes some implementation details, but doesn't break ABI.
--> cygznc-1.7.dll

ZNC 1.8.0 changes order of fields in some struct, breaks ABI.
--> cygznc-1.8.dll

Since upstream agrees to not break ABI between "patch" versions, I don't
see a reason to make the DLL name to not reflect the actual version
number. I think this scheme is also used in the package of ICU library
(except that they don't guarantee ABI compatibility for C++).

>>> You ahould ask Yaakov, but I seem to remember that the preferred way to
>>> name new libraries is now without the hyphen.
>>
>> Hm, ok...
>> Yaakov, what's the plan?
> 
> Dunno about Yaakov, but what counts in the first place is to keep track
> of the ABI change and only bump the ABI version attached to the DLL name
> if a new version of the base package breaks it.  The ABI version itself
> is mostly maintained by the project's build system.

I agree about not breaking ABI without changing the filename. This
question was not directly related to ABI, however, but is about hyphen.
For consistency with existing libraries, hyphen is needed, I think. But
if the policy for new libraries to not use hyphen, I'm fine with that too.