[OctDev] release goals

[Paul K. <pki...@ja...>]

Hi all,

I've been thinking about what we need for our semi-annual release of
octave-forge.

Clean support for 2.1.36 and the upcoming 2.1.37 are definite
show-stoppers.  I'm not comfortable abandoning the older versions
though.  

The changes required for .cc files we could do through configure by 
testing for certain functions which changed since 2.1.35. The alternative 
is to test against specific octave version numbers in the code.  E.g.,
	#define _VERSION(a,b,c) (((a)<<16) + ((b)<<8) + (c))
	#define OCTAVE_VERSION _VERSION(OCTAVE_MAJOR,OCTAVE_MINOR,OCTAVE_PATCHLEVEL)
	#if (OCTAVE_VERSION > _VERSION(2,1,35)
	   ...
        #else /* OCTAVE_VERSION <= 2.1.35 */
	   ...
	#endif
I'm in favour of the latter because it will be easier to implement.  

Off the top of my head, struct/*.cc and FIXES/fsolve.cc are broken.  A more
difficult problem is that lo-sstream.h is missing from the octave installation
so a lot more things look broken than really are.  I suppose we could
keep our own copy somewhere (e.g., in FIXES) and use -I$(TOPDIR)/FIXES if
octave version is 2.1.36.  Or we could just document the problem.

Unfortunately m-files will also have to change:
	* replace ... with varargin/varargout
	* replace all_va_args with varargin{:}
	* for [v,k]=struct ... end now sets v to a list rather than a value
	* anything else?

We could use version tests in our code.
We could use a preprocessor and set up make to convert file.m.in to file.m.
We could have file.m-2.1.35 for example for versions up to and including
2.1.35 and file.m for later versions.

I'm in favour of using a preprocessor because I'm not very good at fixing
the same bug in multiple files, and since I do not want the overhead of run
time version checks.  The preprocessor could either strip the conditional
code that isn't used or it could comment it out.  I prefer stripping it
entirely as a way of reducing the cruft we present to the user.  Anyone
want to write this?  Or could we use something like the C preprocessor or
M4 directly?  Note that a preprocessor will also be useful to those who are
trying to support both octave and matlab from the same codebase (e.g., ode
and tsa) --- you might want to consider this in the design.

A number of functions from octave-forge have been incorporated into 
octave.  We need to conditionally ignore them during build and install.

Adding test support to the makefiles for all the directories and running
all the existing tests during make check is a worthy goal, but I doubt I
will get to it this time round.

Anything else?

Paul Kienzle
pki...@us...