[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] glpk 4.48 release information

From: marco atzeri
Subject: Re: [Help-glpk] glpk 4.48 release information
Date: Tue, 29 Jan 2013 12:11:09 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2

On 1/29/2013 11:50 AM, Andrew Makhorin wrote:
Hi Marco,

Thank you for your comments.

I will not call a API version change a maintenance release

changing from 32:0:32 to 33:0:0
is a major change as compatibility with the past is lost

Formally, it is. However, changes concern only a few *auxiliary* api
routines, some of which (for plain text processing) were removed as
inappropriate. So I wouldn't consider these changes as major ones.

to avoid the jump from cygglpk-0.dll to cygglpk-33.dll
I will deploy cygwin package with 33:0:32 that will just
stop at cygglpk-1.dll

I followed instructions given in the manual

which says:

1. Start with version information of ‘0:0:0’ for each libtool library.
2. Update the version information only immediately before a public
release of your software. More frequent updates are unnecessary, and
only guarantee that the current interface number gets larger faster.
3. If the library source code has changed at all since the last update,
then increment revision (‘c:r:a’ becomes ‘c:r+1:a’).
4. If any interfaces have been added, removed, or changed since the last
update, increment current, and set revision to 0.
5. If any interfaces have been added since the last public release, then
increment age.
6. If any interfaces have been removed or changed since the last public
release, then set age to 0.

According to these rules 32:0:32 becomes 33:0:0, because some api
routines were changed/removed. Or I did something wrong?

Andrew Makhorin

your approach is correct as general rules,
my approach is just to avoid the 0 to 33 jump.

"c:r:a" has no usage on cygwin, "c-a" is api version.

I will check internally if we are still using this approach or not,
I have no other packages with such huge jump


reply via email to

[Prev in Thread] Current Thread [Next in Thread]