On 1/12/12 9:33 AM, Balint Reczey wrote:
> On 01/12/2012 06:20 PM, Gerald Combs wrote:
>> On 1/12/12 9:06 AM, Gerald Combs wrote:
>>> On 1/12/12 1:59 AM, Balint Reczey wrote:
>>>
>>>> I'm not sure that it is the proper approach.
>>>> We don't have to update the library version if there is no change in
>>>> the
>>>> lib.
>>>
>>> The libtool documentation says "If the library source code has changed
>>> at all since the last update, then increment revision (‘c:r:a’ becomes
>>> ‘c:r+1:a’)." We update
>>
>> [ hit "send" too soon. ]
>>
>> We update the code in epan and wiretap in every release, which means the
>> revision number should be incremented for libwireshark and libwiretap,
>> correct?
> I can imagine a release without any change in those libraries, this is
> why I wrote that it may not be the proper approach, but you are correct,
> if there are only internal changes in both libs, we should update the
> revision for both.
It's certainly possible to create a release that doesn't change
libwireshark or libwiretap. We've done it a few times the past (e.g.
1.0.16 fixed some Windows DLL hijacking flaws), but that case is very rare.
(In case you're wondering why I'm being stubborn about this, the
Wireshark release checklist is currently *3 pages long*. Adding manual
steps makes a long process even longer and makes it more error prone.)
> Since we can change the ABI as well I propose running ACC before the
> release and manually updating the versions properly or creating a script
> which updates
> the version numbers properly according to ACC.
I propose running it as far in advance of each release as possible. :)
Having something we could run as a Buildbot step (that is, a makefile
target or a shell, Python, or Perl script) would be fantastic.