I agree with Andrew's first paragraph (and I don't know enough about libtool to endorse the second).
> Is it something that alone calls for a new release (1.1.5) or can we just > update svn? What implications does bumping the SONAME have? The Fluidsynth soname is currently libfluidsynth.so.1. As far as I know, it is up to each library to decide whether the soname is the MAJOR.MINOR or just the MAJOR. The Linux HOWTO on Shared Libraries (http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html) recommends that the soname is just the MAJOR (which is consistent with FluidSynth). However it is arranged, you need to bump the soname when binary compatibility is broken. This would mean that going up to 1.1.5 or even 1.2 wouldn't work, because the soname would still be libfluidsynth.so.1. So if you want to change the soname, I think you have two options: - Release FluidSynth 2.0, with soname libfluidsynth.so.2, or - Change the soname policy to MAJOR.MINOR and release FluidSynth 1.2, with soname libfluidsynth.so.1.2 You should not change the soname policy to MAJOR.MINOR.REVISION, because otherwise each revision release will be binary-incompatible with the previous one. (In fact I just talked another project out of this soname policy yesterday!) I'm not suggesting you do either of the above things -- I don't think this warrants a major (or even minor) version release. Since this is the removal of an undocumented API feature, I would say you are within your "contract" to do it without changing the soname. _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
