-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/29/2013 06:46 AM, Michal Židek wrote:
> On 04/25/2013 05:18 PM, Stephen Gallagher wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 04/24/2013 06:11 PM, Simo Sorce wrote:
>>> On Wed, 2013-04-24 at 20:55 +0200, Sumit Bose wrote:
>>>> On Wed, Apr 24, 2013 at 02:22:42PM -0400, Stephen Gallagher
>>>> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>
>>>>> On Wed 24 Apr 2013 02:05:55 PM EDT, Michal Židek wrote:
>>>>>> New version of the patch is attached.
>>>>>>
>>>>>> Changes from previous iteration: - version-info set to
>>>>>> 0:2:0 - init function remains backward compatible, but it
>>>>>> sets default oadptions needed for range calculation. Non
>>>>>> default values can be set via ded setters. -
>>>>>> sss_idmap_opts moved to private header
>>>>>
>>>>> This is still a backwards-incompatible break. If we were
>>>>> presenting a data structure in a public header and no
>>>>> longer are, it's an ABI break. Is there any way to avoid
>>>>> this?
>>>>
>>>> sss_idmap_opts is introduced with this patch, it was in the
>>>> public header in the first version and Michal moved it into
>>>> the private one in the new version.
>>>
>>> I think Steven was referring to struct sdap_idmap_slice
>>> disappearing from src/providers/ldap/sdap_idmap.h maybe ?
>>>
>>
>> Actually, I hadn't looked at the patch. I saw that he had moved
>> a structure from a public to a private header and didn't realize
>> it was a newly-added structure.
>>
>>
>> One nack: the version-info string needs to be 1:0:1 according to
>>
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-inf...
>>
>>
>>
>>
This is because you have added the getters and setters to the public
>> interface, which means that all of steps 3, 4 and 5 in that
>> guideline must be followed, which results in a value of 1:0:1 for
>> version-info. Note: this arrangement does NOT result in a SOname
>> bump, because the "age" is equal to the "current" (Which
>> effectively means that we're saying that this interface is a
>> proper superset of all interfaces that have preceded it).
>
> Thanks a lot for the explanation Stephen. I was actually following
> the same guide, but I thought that only one rule is applied each
> time version-info is changed, which did not make much sense in
> some situations. Now it finally makes sense to me.
>
> New patch is attached.
>
Ack!