Jeff Spaleta wrote: > On Wed, Feb 11, 2009 at 8:04 AM, Mikkel L. Ellertson > <mikkel@xxxxxxxxxxxxxxxx> wrote: > > This maybe expected for libraries which advertises a stable API, but > its not a hard and fast rule for all libraries..especially for > libraries which do not advertise themselves as stable. Do we have an > accurate accounting of which upstream library projects consider their > API stable and follow the soname conventions? Or do we just assume > they are? > > Take xulrunner for example, only a subset of the functions it exports > for applications to use are considered stable. This is the reason why > xulrunner has a -devel and a -devel-unstable subpackage. Any > application which is making use of xulrunner function calls which are > identified as unstable...will need to be rebuilt with each and every > minor revision of xulrunner to ensure proper operation...regardless of > the soname changes on the library. This is why every time there is a > xulrunner update, a flurry of additional application packages are > rebuilt and pushed as well. > > > -jef > It sounds like your example is the exception to the rule. And even here, they attempt to prevent the problem by separating stable and unstable. But there is a general rule when it comes to numbering, and it should be followed by all projects. But there are always a few people that do not "play well with others" and do not follow the rules. By the standard develop numbering scheme, you are supposed to change the major number when the API changes. Thus you do not change from version x.y.z to x.y.z+1. Depending on the changes, you would change from x.y.z to x.y+1.0 or x+1.0.0 to show how much things have changed. Also, versions numbered 0.0.x are not normally considered stable - at best they are beta quality products. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
