2010/9/14 Julian Taylor <[email protected]>
> > That way, Mateusz' initial proposition seems sensible: SOVERSION ==
> > MAJOR.MINOR
> > For instance, I have never seen libraries with soname version made of
> > large numbers (say, e.g., soversion >= 20), which would be the case if
> > we just increase the soname version each time a release is made.
> > What do you think?
>
> There are libraries with high sonames, e.g. libmysqlclient is 16+
> and libx264 even has a number higher than 80
>
Yes, but it remains rare.
> The last soci release was 2 years ago, I do not think we have a problem
> of exploding soversion if the pace does not change radically.
>
That's the main point, and I fully agree with you :)
I would stick with a unrelated number increased on change as almost
> every other library out there.
>
It's just that it's then harder to maintain: who will decide when to bump
the soname version? When? How? Should there be a procedure for that? etc. In
contrast, the major.minor scheme is easier to maintain, since it is
automatic (as it follows the version numbering scheme).
But, really, I do not care that much, beyond the maintenance issue, about
which soname version scheme will be adopted (and as I'm not really a
maintainer, it's not really my problem either). Provided there is a
consistent soname version scheme, I'll be happy to continue packaging Soci
:)
D
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
