OCTAVE_API_VERSION without '+' character?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

OCTAVE_API_VERSION without '+' character?

Rik-4
Mike,

I notice that the release task you moved was

Increment oct file API version number (configure.ac:OCTAVE_API_VERSION,
increment number and drop "+" suffix)

Do we need the '+' suffix on OCTAVE_API_VERSION anymore?  If today's
(4.4.1) API version is 52, wouldn't it make sense to have the stable be 53,
and the development branch be 54?

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: OCTAVE_API_VERSION without '+' character?

Mike Miller-4
On Mon, Jan 21, 2019 at 10:47:47 -0800, Rik wrote:

> Mike,
>
> I notice that the release task you moved was
>
> Increment oct file API version number (configure.ac:OCTAVE_API_VERSION,
> increment number and drop "+" suffix)
>
> Do we need the '+' suffix on OCTAVE_API_VERSION anymore?  If today's
> (4.4.1) API version is 52, wouldn't it make sense to have the stable be 53,
> and the development branch be 54?
I agree stable should be updated to "api-v53".

It could be discussed whether we still need to have an API version
string that changes between the development branch and the stable
release (53 → 53+ → 54).

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.

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.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OCTAVE_API_VERSION without '+' character?

John W. Eaton
Administrator
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

Reply | Threaded
Open this post in threaded view
|

Re: OCTAVE_API_VERSION without '+' character?

Mike Miller-4
On Mon, Jan 21, 2019 at 14:27:18 -0500, John W. Eaton wrote:
> Yes, and to say "this is a development version; interfaces may be changing
> without a change in the version number".
[…]

> 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.
Ok, then the default branch should remain "api-v53" until just before
the Octave 6 release?

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OCTAVE_API_VERSION without '+' character?

Mike Miller-4
On Mon, Jan 21, 2019 at 12:17:52 -0800, Mike Miller wrote:

> On Mon, Jan 21, 2019 at 14:27:18 -0500, John W. Eaton wrote:
> > Yes, and to say "this is a development version; interfaces may be changing
> > without a change in the version number".
> […]
> > 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.
>
> Ok, then the default branch should remain "api-v53" until just before
> the Octave 6 release?
I've now updated the stable branch to "api-v53" for Octave 5.

After we merge this to the default branch, do we want to keep it
"api-v53" until we bump the library versions again just before the
Octave 6 release next year?

--
mike

signature.asc (849 bytes) Download Attachment