On Tue, Apr 5, 2011 at 7:48 PM, Orion Poplawski wrote:
> On 04/05/2011 06:36 AM, Ed Hartnett wrote:
>>
>> marco atzeri writes:
>>
>>> Dear Developers,
>>> I just built netcdf-4.1.2 on cygwin, without fortran and c++ as they
>>> are broken compared
>>> to the previous 4.1.1, and I was surprised to see that
>>> the outcome dll is now cygnetcdf-7.dll instead of cygnetcdf-6.dll of
>>> 4.1.1
>>>
>>> Have you made a abi bump between 4.1.1 and 4.1.2 ? If so should be
>>> better to change
>>> the release number ? Between 4.1.1 and 4.1.2 I would expect minor
>>> changes and bug fixes only.
>>>
>>>
>>
>> Howdy Marco,
>>
>> The library ABI number went up because we changed the main API (by
>> adding the nc_inq_path function.)
>>
>> We did not change the library version number to 4.3 because this was
>> such a minor addition.
>>
>> In general, the ABI version has nothing to do with the version number of
>> the package.
>>
>> Thanks,
>>
>> Ed
>
>
> My thoughts:
>
> - According to
> http://linuxtesting.org/upstream-tracker/versions/netcdf.html, the main ABI
> problems with going from 4.1.1 -> 4.1.2 was:
>
> ncEnumType.h
> namespace netCDF
> [-] NcEnumType::ncEnumType (5)
> Change Effect
> 1 Value of field nc_INT64 has been changed from 8 to 10. Applications
> may execute another branch of library code.
> 2 Value of field nc_UBYTE has been changed from 5 to 7. Applications
> may execute another branch of library code.
> 3 Value of field nc_UINT has been changed from 7 to 9. Applications
> may execute another branch of library code.
> 4 Value of field nc_UINT64 has been changed from 9 to 11. Applications
> may execute another branch of library code.
> 5 Value of field nc_USHORT has been changed from 6 to 8. Applications
> may execute another branch of library code.
> [+] affected symbols (1)
> NcGroup::addEnumType ( std::string const& name, NcEnumType::ncEnumType
> basetype ) const:
> 2nd parameter 'basetype' has type 'NcEnumType::ncEnumType'.
>
this seems a change in the CXX4 interface, not in the C interface
> Kind of scary when constants change values.
I agree
>
> - Adding a new function does not require bumping the soname version because
> that is still backwards compatible.
I agree, and I was expecting no change for just additional functionalities.
> - Distribution and system maintainers must pay special attention to ABI
> compatibility. A significant version bump is a good indicator that this may
> happen and to look out for it. Conversely, "patch" level version changes
> are not expected to have ABI changes.
making a not needed ABI change create additional workload to the
package maintainers.
Old programs using the previous ABI version can not appreciate any
bugfix in the new ones.
We need eventually support multiple package versions, and this should
be avoided as much as possible.
> --
> Orion Poplawski
Marco
