[Gretl-devel] nasty bug in gretl 1.7.3

[Sven Schreiber]

Am 09.03.2008 15:52, Allin Cottrell schrieb:
> On Sun, 9 Mar 2008, Allin Cottrell wrote:
> 
>> I've found and fixed a nasty bug lately...
> 
> To clarify: this bug was new in 1.7.3; the breakage occurred in a 
> CVS commit on February 6.  Also, the changes in current CVS are 
> summarized as follows:
> 
> - Fix for ADF-GLS test with missing values
> - Fix for detection of unit-diagonal matrix (oops!)
> - Add $fcast and $fcerr accessors for use with fcasterr
> - Autocorrelation test: use Kiviet's original 1986 formula
>   for the LMF statistic
> - system command: enable naming of systems in the manner
>   "sysname <- system"
> - system command: several other changes (write this up when 
>   done)
> - remove obsolete commands: fit, multiply
> - consolidate the commands corc, hilu and pwe into one new
>   command with options: ar1
> - merge with fcasterr command with fcast
> - Fix for the case of graphing 6 time series together
> - Fix bugs 1908139, 1909469
> - Fix documentation of $stopwatch
> - Move handling of strings into "genr"
> - Fix sub-sampling bug (which was new in 1.7.3)
> 
> The changes to commands mentioned above (ar1, fcast) should mostly 
> be user-invisible: I've kept the old forms (e.g. "corc", 
> "fcasterr") as aliases for the present.  The exception is 
> "multiply", which struck me as very ad hoc and which is gone 
> altogether.
> 
> The new handling of string variables may require changes to some 
> scripts but it's definitely an improvement.  



You asked for opinions --

in principle I'm all for using the current source (cvs) for a new 
release, I don't see why other improvements shouldn't be included in 
1.7.4. Of course there may be new bugs introduced by the changes, but 
c'est la vie.

however, in general I would welcome a little more formal policy with 
respect to changes that are backwards-incompatible by design. Currently 
it seems to me that one has to be something of a gretl insider (closely 
following mailing lists etc.) to realize when code will break. So in 
that sense I'm not sure if the backwards-incompatible changes should be 
included in an "emergency release" which is essentially done to fix a 
single severe bug.


just my 2ct

-sven