>> 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.