octave-maintainers
[Top][All Lists]
Advanced

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

Re: Fwd: [swig:bugs] #1353 Octave 3.8.0 support


From: William S Fulton
Subject: Re: Fwd: [swig:bugs] #1353 Octave 3.8.0 support
Date: Wed, 8 Jan 2014 04:46:43 -0800 (PST)

I've just joined the list. Commit
http://hg.savannah.gnu.org/hgweb/octave/rev/b6b6e0dc700e looks like it will
satisfy our needs. Thanks for restoring some sort of usable versioning. 

In my experience working with 20 odd different scripting language's C/C++
interfaces, APIs are inevitably expanded and changed (either unintentionally
or deliberatly) and having a release version number is vital in working with
or working around these additions/changes. 

I agree that having the program version, rather than an API version, is a
more reliable approach. Forgetting to change the version number in all
places is of course a common problem, but I think this can be easily
mitigated. Two solutions you could consider:

- Add a test to your test-suite to check correlation between the version
numbers that are manually set to ensure consistency. Presumably you don't
forget to update the program version!
- Have the version number driven from one location. The common approach
(which SWIG roughly also uses) is to set it in AC_INIT in configure.ac (I
see Octave does this already) which generates header files containing the
version string. Then a simple script in the build process can parse the
header to create further header files/scripts/whatever you need with the
MAJOR MINOR etc version numbers if necessary.

With regard to dev releases, I don't think anything should be expected as
they are in a state of flux. Just official releases should have version
numbers set up correctly.

A couple of questions:
- Probably we can convert OCTAVE_API_VERSION_NUMBER into the new
OCTAVE_{MAJOR,MINOR,PATCH} in our headers that user Octave for the older
versions and only use these new macros going forwards. Is there a simple way
you can suggest to back out this info, other than trawling through mercurial
commits?
- Given we are expected to use features as a way of determining if an API is
available, where would one find info/docs on the C macros correlating to
APIs available per feature?

William




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Fwd-swig-bugs-1353-Octave-3-8-0-support-tp4660724p4660791.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


reply via email to

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