packaging a new LibLo release

[Stephen Sinclair]

Hello,

It was suggested I write to this address for questions about packaging
liblo.  I am the liblo maintainer, and I'm starting to prepare for a
new upstream release 0.27 of this library. I just wanted to verify a
few things before doing the release.

My goal for this release is to ensure that there is no need to change
soname versioning, and that packages depending on liblo do not need to
be recompiled.

I have used icheck to verify that the ABI and API are
forward-compatible.  (But not backward-compatible.. some functions
have been added.)

However, one thing that has changed is that there used to be a line,

#include <pthread.h>

in one of the headers.  I have removed this line since it is not
necessary, however icheck fails unless I add it back to one of the
headers.

>From a packager's point of view, is it worth adding it back to satisfy icheck?

Anything else I should consider in terms of packaging from an upstream
point of view?  I'd like this to go as smoothly as possible, since
I've made mistakes in the past.

Jonas Smedegaard has already reminded me of the issue with the
premake4.exe binary that I included in the last release for Windows
users.  This was mainly inspired by ODE (ode.org) that includes it as
a solution to generate Visual Studio project files.

I'm happy for alternative suggestions on how to provide a source-only
release while still allowing a smooth experience for Windows users.  I
suppose I could ask them to download premake separately..

thanks,
Steve