Re: Api-versioned directories in Octave

[John W. Eaton]

On 21-Feb-2005, Rafael Laboissiere <address@hidden> wrote:

| This brings me back to my original question: is the api-version number
| related to loadable modules only or also to the Octave language itself?

When incrementing that version number, I typically think about changes
in the Octave libraries that could make .oct files compiled for old
versions of the library fail with a new version.  This could happen
when *any* function in Octave changes it's interface, or if a public
function is removed.  If we define a "stable recommended api" and tell
people that they should only use those functions that are in that api
when writing .oct files, then the situation is only slightly better,
because we have no good way of preventing people from using functions
that are not in the recommended api.

It could also apply to changes in any functions implemented in .m
files, but I typically don't think about that when incrementing the
api version number.

| I personally like the api-specific directory for .oct files and I am planing
| to use them for the Debian packages.  Using it instead of the
| version-specific directory will avoid incompatibilities among packages for
| every new version of Octave released.  Packages will need rebuild only when
| the api-version number bumps.  Of course, this is no absolute guarantee that
| pacakges will work across different versions of Octave, but this would be
| better than our current situation in Debian.
| 
| In sum, I would vote for keeping the api-specific directory(ies).

OK, then I won't change anything.

jwe