Re: [XForms] fl_library_version function

[LukenShiro]

Il giorno Sat, 11 Dec 2010 22:55:38 +0100
Jens Thoms Toerring <address@hidden> ha scritto:
> And I must admit that it probably wasn't such a brilliant
> idea to introduce changes in the library that make it in-
> compatible with previous versions witout at least raising
> the revision number. But then I was too much in awe of the
> mythical "1.1" release promised for years;-) In hindsight
> I guess it would have been better to call the first version
> with incompatible changes 1.1, even though if it was not
> yet the "promised land" release as that I came to regard
> a version with those numbers...

First of all, you have absolutely _no_ need to be sorry! As i said
about one year ago, I thank you deeply for keeping this library "alive"
for the time being, with a constant and appreciable maintenance, I also
thank you for your dedication in it, easing my development. The last
thing I want to do is to criticize other's work, to disrupt other's
use-experience, pushing backwards incompatibilities, or to influence
the further development pressing towards one direction or another,
burdening your work. Just to be clear :)

> Perhaps this would also be a good starting point for a
> discussion what needs to be done before we call something
> version 1.1. Once that would be out we could go on in the
> way it was intended originally, using the fix-level number
> only to distinguish minor changes (i.e. just bug fixes etc.)
> and otherwise increment the revision number.

I will chime in the separate thread, as soon as possible.

> What I can do is to introduce a new function that also returns
> the fix-level in some form. If that would be of any help for
> you just let me know what that function should do to be con-
> venient for you to use. 

I believe an additional simple function returning major version, minor
version/revision, fixlevel would be more than enough. I am
python-biased and not so much C-expert, but I suppose e.g.
void fl_completeversion (int * majorver, int * minorver, char *
fixlevel);
Or in the next major/minor version maybe the fixlevel could be a
numeric-only value (so int * fixlevel) 

> But, of course, that won't help for
> the older versions... And then there's also the problem that
> trying to even trying to call that new function when an older
> version is installed would be impossible, you couldn't even
> link your Python wrapper to them (or trying to use the wrapper
> when it was compiled on a machine with the newer XForms version
> on a machine that only has an older version would make the
> run-time linker get really upset, resulting in some nasty
> comments from the python interpreter if it survives...)

Using the tool I'm developing with (ctypes) to do a glue between
python and C, I don't have to manage a really dynamic linking to a C
shared library (as normal binary executable or .so do); when a user
calls one of my wrapping functions it loads on-the-fly XForms library's
corresponding function: if it is not existent python gives him an
easily catch-able Exception e.g. an AttributeError, AFAIR. To make a
long story short: if a function is missing, it triggers the said
exception, and we know we are surely in front of an older version.
Moreover my development is necessarily a 'moving target' (at
least until my first stable version) with no backwards compatibility
needed, so it is definitely not a trouble on my part, indeed.

> If I had given more thought to that problem you actually should
> never have gotten into this mess. Having to find and parse the
> forms.h file is definitely not how things should need to be
> done!

No problem. If an alternative "get_version" function will be available,
I could use current routine only as fallback, if necessary.

> Perhaps the best solution for the future (unfortunately I
> don't know any hacks to change the past) might be to move
> back to a more sane versioning scheme, releasing version 1.1
> next instead of having an 1.0.94, 1.0.95 etc. version. Then
> you would need that rather ugly hack only for the old ver-
> sions (for which it is needed anyway since retroactively
> changing the behaviour of fl_library_version() isn't an
> option). But before I take this step I would like to get
> a bit of feedback also from other people since I am not sure
> if there could be other consequences I don't forsee at the
> moment.

You are certainly right, it's better not to modify fl_library_version.

-- 
GNU/Linux * Slackware64 current
LU #210970 SU #12583 LM #98222/#412913