Re: [XForms] fl_library_version function

[Jens Thoms Toerring]

Hi Lukenshiro (and everyone else),

   sorry for the delay in replying, some other work had
to be dealt with urgently...

On Thu, Dec 09, 2010 at 03:31:36PM +0100, LukenShiro wrote:
> I wonder if fl_library_version function in lib/version.c could be
> edited a bit to be more useful.
> 
> Now using it you can obtain a consolidated version, FL_VERSION and
> FL_REVISION. Is it possible to obtain also FL_FIXLEVEL (if it
> doesn't cause too much trouble)?

The version information is admittedly a bit of a mess. As
far as I can see originally the intention was to have just
a major version and a revision (like 0.89 etc.) and that
fix-levels should be more or less irrelevant. I guess that
at the time when 1.0 came out the expectation was that 1.1
would be just around the corner. But that hasn't been the
case;-) But that way the fix-level has got a life of it's
own which it wasn't supposed to ever obtain.

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...

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.

Unfortunately, I have no good idea how to change that
fl_library_version() function to include the fix-level
without breaking backward compatibility. I can't add another
argument nor can I change the return value without inducing
trouble for programs that rely on the old version.

> Main reason is: between old versions and recent ones (>1.0.92)
> there are many differences, but they are "equal" (1000, 1, 0) according
> to fl_library_version. In python wrapper I'm developing I currently have
> to use a somehow long and not portable hack (parsing forms.h include
> file) to verify if wrapper's version matches XForms library's version;
> using this function it would be definitely more straightforward.

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. 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...)

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!

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.

So, everybody having an opinion on this, please chime in!
Here's a threat: if there are no replies at all (beside from
Lukenshiro) I am going to start a new thread about the topic
on the mailing list!;-)

                            Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de