Re: [fluid-dev] New development

[Pedro Lopez-Cabanillas]

Bernat Arlandis i Mañó wrote:
> This is concerning ticket #11.
>
> I'm thinking on a lot of changes to take FS forward as I review the
> source code and fix some things, but most of these changes would break
> compatibility backwards. Maybe we should think about making a branch for
> something that could be FS2.0. Fixes that break compatibility could go
> there, what do you think? Or we could take intermediate steps that would
> be 1.1, 1.2,... I think it's better working in gradual steps with public
> releases.
>
> I'm willing to push development for that branch since I'm getting to
> know its internals and I like working with it very much, but it wouldn't
> be good to do it completely on my own without your expertise and the
> users support. I don't want this to start a fork neither, so there has
> to be an initial agreement that we all support this branch while it
> accomplishes some goals or we all forget about it.
>
> I know it's a short time since I'm working with the code, but I'm
> already playing with it and there are simple things that can't be done
> without breaking backwards compatibility since the code exposes a lot of
> internals and there's a highly coupling between some components. These
> are issues that keep FS from evolving.
>
> Opinions, please.

Changes breaking the API compatibility, not only for FluidSynth but for any 
ELF shared library (i.e., to be deployed in Linux), should require a change 
in the SONAME internal attribute for the library. This is usually 
accomplished changing the major version number. As reported by the objdump 
utility:

$ objdump -p /usr/lib/libfluidsynth.so | grep SONAME
  SONAME      libfluidsynth.so.1

Why to bore with this? Because libfluidsynth.so is used by many programs, as 
QSynth (I'm a contributor for it) and the others reported by Julien. Using 
different SONAMEs allows the old library version to be installed alongside of 
the new one, to be used at runtime in the same box. The programs using the 
old library can still run before they evolve to adopt the new one.

So, yes. I would open a new FS2 branch for changes breaking API compatibility 
and architecture changes. Maybe this would be the place to introduce the glib 
dependency that Josh has in mind. Anyway, I would like to ask that before 
coding a lot, please (briefly) explain your proposals.

Regards,
Pedro