Re: A group in Norway starts to develop support for multidimensional arrays in Octave.

[Etienne Grossmann]

On Thu, Jun 19, 2003 at 08:39:57PM -0500, John W. Eaton wrote:
# On 20-Jun-2003, Joao Cardoso <address@hidden> wrote:
# 
# | And some distributors also. Octave is not available under SuSE since
# | SuSE-8.0; the problem, I think, is that the stable octave version
# | can't be compiled with the shipped gcc.
# 
# I think this has changed.  Although it doesn't show up in the
# package database on their web site, someone told me that it is on the
# latest CD.  I see an RPM file for 2.1.44 on one of their ftp mirrors.
# 
# The problem with making a stable release is that I don't want to waste
# my time patching it with fixes that I have already made to the
# development version.  I tried that before and it didn't work for me.
# It took too much energy to keep up with fixes for the stable release.
# After only a short while it was not nearly as simple as making diffs
# from the development CVS and applying them to the stable sources.  If
# someone good would seriously consider taking over a stable release,
# then I would consider it.  I have asked in the past, but no one
# volunteered.  Maybe things are different now.  If so, and you would be
# interested in this job, then speak up.  Otherwise, there is no way I
# plan to do it.  I don't see the point of having a particular version
# frozen and called stable when it might have serious bugs that would
# never be fixed in an updated release.
# 
# Another possiblity is to do away with the 2.0.x series and just have
# one.  It would not be labeled "stable" or "development" or anything
# else.  Then if you want Octave, you get the latest version.  We would 
# make releases when we felt comfortable that things were mostly OK and
# people who want to work with the latest sources would use CVS.
# 
# jwe

  Hello,

in summary, it looks as if you could call 2.1.50 "stable" (perhaps
rename it 2.0pre1).

  Each time 2.1.{n+1} comes out, wait a week.

  If seriousness_of_detected_bugs < some_subjective_threshold 
  then call 2.1.{n+1} "stable".
  else "stable" stays whatever it was before.

With that scheme, 2.46 (iirc) would have become stable, but not 2.1.47
(m-file date stamp problem). Stable would never be more than a few
versions away of "unstable" (or "testing", in Debian terms).

  Just the 2c I got from this thread.

  Cheers,

  Etienne

-- 
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne