Re: OCTAVE_API_VERSION without '+' character?

[John W. Eaton]

On 1/21/19 2:06 PM, Mike Miller wrote:

> I would guess that it was done that way to make sure that Forge and
> other external oct files were actually recompiled after a release was
> made.

Yes, and to say "this is a development version; interfaces may be 
changing without a change in the version number".

> Let's say we make the default branch be "api-v54" now, and not change it
> when Octave 6 is released. The only down side is that a user may build
> an oct file against the development version in September and not realize
> that it needs to be recompiled after the release, until they see a crash
> or other weird runtime behavior.

The original goal of the API version was to avoid loading .oct files 
that were compiled and linked with incompatible versions of the Octave 
libraries.  At one time I thought we could avoid needing the API version 
if we used proper library versioning.  But now we don't link .oct files 
directly with the Octave libraries, so I assume we still need this 
version number to detect mismatch?  In place of using our own API 
version, could we encode the liboctave and liboctinterp version numbers 
in the .oct file and use the same rules to determine whether the .oct 
file will work with the Octave libraries that are currently being used?

In any case, since the API version is supposed to do the same thing as 
the shared library version, I think they should be updated at the same time.

jwe