[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Curiosity about release numbers

From: dave
Subject: Re: [fluid-dev] Curiosity about release numbers
Date: Thu, 18 Mar 2021 22:47:06 -0000

Hi FluidSynth community,


I too have been a little confused by version numbering.    A few weeks ago I downloaded what I understood to be v2.2 (possibly beta) of the 32bit Windows build.   This introduces a fix for tempo changes in the scheduler and I can now schedule them, and it works perfectly – for which my heartfelt thanks!   I’m impressed!

The package I downloaded came with 7 DLLs, and I assume I need all of them.   But checking that I had upgraded consistently from v2.1 was a little difficult.   Apart from a change in name of one of the libraries I have now using versions


intl.dll                           [0.18.1]

libfluidsynth-3.dll         []

libglib-2.0-0.dll           [2.28.8]

libgobject-2.0-0.dll   [2.28.8]

libgthread-2.0-0.dll   [2.28.8]

libinstpatch-2.dll              no version info

libsndfile-1.dll           []

where the first number is the file version and the second, in [ ], is the product version.   It all works fine, but it isn’t obvious from the version numbers, or the file names, that I have a consistent set with version 2.2!    Would it be possible to rationalise all this (file names and version numbering) for us confused (but enthusiastic) users?

And echoing Pascal…

Thanks a lot for this beautiful piece of software!




From: fluid-dev <fluid-dev-bounces+dave=mozart.co.uk@nongnu.org> On Behalf Of Tom M. via fluid-dev
Sent: 17 March 2021 21:44
To: midi-pascal <midi-pascal@videotron.ca>
Cc: Tom M. <tom.mbrt@googlemail.com>; FluidSynth mailing list <fluid-dev@nongnu.org>
Subject: Re: [fluid-dev] Curiosity about release numbers


2.1.8 is the version of the project, that any maintainer is free to choose as he pleases.


2.3.8 is the version of the library-interface. It tells you about API/ABI stability because follows the strict semantic versioning rules originally implemented by libtool. See the comment here:


And libtool docs here:


Sometimes we have bugfix releases that add new public functions. In this case, we must increment the minor version of the library-interface. Whereas for the "project"-version we would just increment the micro level (as those are just bug-fixes). In any case, those are two completely different versions, that coincidentally look very similar at the moment :)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]