[XForms] Version numbers and next release - please read!

[Jens Thoms Toerring]

Hi erverbody.

  in a recent mail to the mailing list Lukenshiro brought it
to my attention that what I did with the version numbers of
XForms was rather stupid. If you haven't read the exchange
here's a summary of what it's about:

   In the beginning there were version and revision numbers
(or, at least, that's what I guess were the original inten-
tions). For minor bug fixes also a fix-level would be used
but that wasn't anything that was "advertised" by the li-
brary. So we had 0.88, 0.89, 1.0. With 1.0 in 2002 we had
the switch to the library becoming open source. During that
time expectations were high and the release of version 1.1
seemed to be just a matter of months (if I remember correct-
ly). As we all (or at least the nore long-time members of
the mailing-list) know, things dragged on a bit and we're
still not at version 1.1 yet, instead there were a number
of releases where just the "fix-level" number was bumped
up, so we now have 1.0.91, 1.0.92 and 1.0.93 and, perhaps
in the near future, 1.0.94.

   What's the problem with that? Using functions supplied
by the library (fl_library_version()) one can only deter-
mine the version and revision number, but not the fix-level
(i.e. 0, 91, 92, 93 etc.), so 1.0, 1.0.91, up to 1.0.93 all
are reported as the 1.0 version. And with that I messed up
things quite a bit since now versions which aren't compa-
tible are indistinguishable by using functions in XForms. So
some functions may have vanished, others may have gotten
added, internally used structures have changes quite a bit
etc. but it's not possible to find out easily.

   If you compile your programs using Xforms yourself that
probably isn't that much of an issue (if you have to you can
check the fix-level with a bit of pre-processor magic). But
once you start distributing your program in binary form or
for people like Lukenshiro, who's writing a Python-wrapper
for XForms, thinks look more dim. They need also the fix-level
information but can't get it without rather ugly and error-
prone hacks (like trying to find and parse forms.h).

   While I can't undo my mistakes from the past I am considering
to go back to a somwehat "saner" versioning scheme, i.e. having
only version and revision numbers making a real difference and
using fix-level numbers for only what they were meant for, i.e.
designating bug-fix releases without any other changes that might
introduce any kind of incompatibilities (that includes introduc-
tion of new functions and whatsoever).

   But: to do that we would have to finally switch to a 1.1
version, Now, I always had somehow considered "version 1.1"
to be something that would address all problems ever expe-
rienced with XForms;-) But perhaps that's expecting a bit too
much and switching to a more useful version numbering scheme
might be more beneficial than waiting for a mythical perfect
version we then would proudly call 1.1.

   So I consider naming the next version I originally intended
to be 1.0.94 to instead 1.1. And from then on we would bump up
the revision number for all changes that aren't just bug fixes.
Now I don't know if that would inconvenience anyone of you and
thus I would like to get some feedback on the whole thing. So
please don't hold back and tell me about all possible problems
you may envision to result from that!

   Another thing I would like to get done before going down
that road (if we decide to do that) is to fix bugs. Christmas
holidays are around the corner, so I might have some extra
time for working a bit more on XForms again than in the last
months. So also report everything you consider to be bugs to
help get them fixed now.

Beside that I would like to have some kind of "development
branch" were we can play around with new ideas and that you
can test if you like to. I have no good ideas yet for a con-
sistent naming scheme for that, so I will be grateful for all
input.
                           Best regards, Jens

===========================================================

On a completely different note (I hope you don't mind):

For those of you that haven't yet heard about it, there's
what I personally consider to be a really fantastic new book
about (system) programming under Linux (and actually more or
less all kinds of UNIX) by the maintainer of the Linux man
pages, Michael Kerrisk: "The Linux Programming Interface",
see e.g.

   http://man7.org/tlpi/

If you enjoyed Stevens' APUE I think you won't be disappoin-
ted. And if you never got around to read Stevens' book(s)
but are looking for "the book" about Linux/UNIX programming,
it might be what you've been looking for all those years;-)

Note: I got asked to comment on a few chapters before publi-
cation and I received a free copy for that, but that's all
about my involvement with the book.
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de