Re: Release 3.4.1

[John W. Eaton]

On  4-Apr-2011, Rik wrote:

| On 04/04/2011 07:14 AM, John W. Eaton wrote:
| > Are there changes that break binary compatibility or any otherwise
| > risky changes that have been applied to the default branch since the
| > 3.4.0 release?
| Is there a simple way to let Octave answer this question rather than having
| to review all the changesets?
| 
| I'm only guessing at a process, but it would be something like this:
| 1) compile and install version 3.4.1
| 2) run octave-3.4.0
| 3) switch all library references over to the 3.4.1 libraries using path,
| EXEC_PATH, and any other internal variables necessary.
| 4) run the full test suite and see if it passes.

I tried a few things.  The closest to what we want to do is probably
the last thing I tried

To see if this would work for the .oct files that are distributed with
Octave, I unpacked octave-3.4.0 and checked out a copy of the current
sources, then

  * changed the API version in configure.ac in both to match

  * changed the "-release $(version)" option for the lib*_la_LDFLAGS 
    variables in the Makefile.am files in the libcruft, liboctave, and
    src directories to be "-version-info 0:0:0" instead (more on this
    below)

  * built both versions

  * exchanged the src/DLD-FUNCTIONS/.libs directories for the two
    versions

  * ran "make check" for both versions

There were no crashes and no new failures for the 3.4.0 tree (using
the development version .oct files) but there were some new failures
for the development tree (using the .oct files from the 3.4.0
version).  I think the new failures are all for tests that have been
added, or bugs that have been fixed and for which new tests were
added. The tests came from the source files, which were not exchanged,
so it's not surprising that they did not match exactly the code being
tested in all cases.

About the "-release 3.4.0" vs. "-version-info 0:0:0" option.  This is
a bug in Octave 3.4.0 which makes 3.4.0 incompatible with any other
Octave version that does not use "-release 3.4.0" to build libtool
libraries.  Apparently when I first converted Octave's build system to
use automake and libtool, I decided to use the "-release $(version)"
option to reproduce the way we had appended version numbers to shared
libraries in previous versions of Octave.  But the effect was not just
to append version numbers, but also to insert the version number in
the link process, so the .oct files for 3.4.0 are explicitly linked to
liboctave-3.4.0.so, which is a mistake, and will prevent them from
being linked to any other library version.  So unless we release 3.4.1
with libraries also named liboctave-3.4.0.so (which I don't think we
want to do) then we already have binary compatibility problems.

Instead of -release, we should be using -version-info
CURRENT:REVISION:AGE as described in the libtool manual and increment
these version tags as needed using the guidelines in the libtool
manual.  Then we have a better way to track binary compatibility of
the libraries.

So given this mistake and the fact that the majority of changes since
3.4.0 are bug fixes or minor improvements, I think it would be best to
just merge the release-3.4.x branc with default, then create a stable
branch and prepare for the 3.4.1 release on the stable branch, then
proceed with the stable/default development workflow that we've been
discussing.  We can make it clear in the release notes for 3.4.1
that it is unfortunately not binary compatible with 3.4.0.  In the
future, any .oct file built for an Octave release 3.4.x should work
with any later release in the 3.4.x series.

Given that we don't have a stable published API I don't think that we
should try to guarantee that any .oct file build for any release 3.4.x
can be used with any other 3.4.x release because to do that means that
we are not even allowed to add new public functions to the libraries.
If we did have a published API for .oct file developers to use, then
I'd be more willing to make this guarantee as well, at least for the
API functions.  But we don't, so it seems quite restricting to require
that we can't add functions to the libraries when fixing bugs.

Comments?

jwe