No dia 7 de Outubro de 2010 06:55, Philip Brown <[email protected]> escreveu: > On Wed, Oct 6, 2010 at 9:42 PM, Maciej (Matchek) Blizinski > <[email protected]> wrote: >> (Phil wrote) >>> I think you might do well to go with my original theory, slightly expanded: >>> >>> Unless you find a shared object, of filename "lib*.so*", AND it has a >>> "SONAME", AND that name has a double-numeric rev (eg: >>> libfoo.so.#.#), then you should just leave it alone. >> >> I understand and I agree with the first two criteria: It makes sense >> to separate the library out, if it is named lib*.so*, and has a >> SONAME. I don't get the bit with the double-numeric versions. What >> matters is the presence of SONAME, and the contents is a conventional >> notation, why would any numbers matter? >> > > (I did explain this previously, but I'll repeat myself for this case)
I didn't mean to make you repeat yourself. I understand the potential (depending on the approach of developers) implication of declaring "we change the API frequently" via including the minor version number and "we offer a stable API" by including the major version only. This tendency is clear to me. What I meant is that the life cycle of an API-wise unstable library consists of exactly the same phases as the life cycle of a API-wise stable library: 1. A SONAME appears 2. We decide to distribute it 3. Binaries start linking to it 4. Time passes, new version of the same library comes along 5. Binaries stop linking to it 6. SONAME goes away Life cycles of SONAMEs might span shorter or longer time frames, but are otherwise identical. Therefore, the packaging policy has no reason to depend on the API change frequency. In other words, if you want to retire your SONAME in a clean and easy way, always put it into a separate package. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
