[Gretl-devel] time for 1.9.8?

Allin Cottrell cottrell at wfu.edu
Thu Feb 23 22:22:46 EST 2012

On Wed, 22 Feb 2012, Riccardo (Jack) Lucchetti wrote:

> On Wed, 22 Feb 2012, Sven Schreiber wrote:
>> Am 21.02.2012 20:02, schrieb Allin Cottrell:
>>> I'm thinking that at this point we have accumulated enough
>>> fixes to warrant a new release. Any other thoughts on this?
>> Just yesterday I thought about the discussion before the Torun
>> conference that gretl 2.0 was imminent... I have no problem with an
>> on-going business-as-usual because that business is running rather well,
>> but originally the plan seemed to be something different to me.
> I don't think that 1.9.8 should be perceived as "two to go before 2.0"; 
> nobody is preventing us from having 1.9.10 or 1.10.1.
> That said, I think you're right; we should start setting our agenda for 2.0 
> for real (up to now things have been a bit fuzzy IMHO) and some brainstorming 
> would be good.

I know we discussed gretl 2.0 issues a while back, and I know I need 
to re-read what was said then, so that previous work is not just 
discarded. But in the meantime here are a few thoughts off the top 
of my head.

One general question: do we want to make a big deal of gretl 2.0, or 
do we want to "do a Linus"?

By "do a Linus" I'm referring to the fact that when Linus Torvalds 
released version 3.0 of the Linux kernel, he was quite emphatic that 
it contained nothing dramatically new: it was a regular update which 
would have been numbered 2.6.34 except that Linus had got tired of 
the endless 2.6.NN series and decided to rebase the numbering.

In gretl's case it would be quite natural to roll over from 1.9.9 to 
2.0.0. As Jack says, we could instead roll to 1.10.0 (or 1.9.10) but 
multi-digit minor numbers are perhaps a little unsightly and liable 
to cause confusion in some contexts.

OK, so much for doing a Linus: what's the case for making 2.0 a real 
milestone? (And deferring that milestone until something special is 
ready.) I can see a few possibilities (there may be more). Version 
2.0 should contain one or more of:

1) Major new functionality

2) Major changes in the GUI

3) A major backward-incompatible clean-up of hansl

4) A major change in the libgretl API, to make it easier for third
   parties to use

5) A major purge of bugs and update/completion of documentation

My current thinking (sorry if this is disappointing!) is that number 
5 provides the strongest case for a "2.0 milestone". Let's go 
through the list.

* Major new functionality: Well, if we're talking C code, then at 
present that means stuff that Jack and I will produce. I put my view 
on this at the 2011 gretl conference: I think we now have a good 
enough baseline that people ought to be able to add functionality to 
gretl in the form of function packages and "addons". I certainly 
stand ready to fix bugs and tweak the C code (including the GUI code 
and the "gretl server" infrastructure) to make that easier. But 
right now I myself have no plans to add major econometric 
functionality in C form. Jack has been working on substantial new 
stuff, but in the form of (brilliant) hansl code rather than C.

* Major changes in the GUI: That's up to me alone, and I have no 
plans in that area. Nor do I expect to have time to implement truly 
big ideas that others may come up with, though I'm always ready to 
consider incremental improvements and bug fixes.

* Major backward-incompatible clean-up of hansl: consistency and 
cleanliness are good, but so is continuing backward compatibility. I 
can surely see a case for scrapping some archaisms. But I seem to 
recall some folk wisdom from computer science: the production of a 
backward-incompatible "cleaned up" version 2 of language L often 
results in fragmentation of the user base and decline of L.

* Clean-up of the libgretl API: A good idea. But this can be done 
without much (if any) change that is visible to users of gretl 
itself, so it's probably not very pertinent to the "2.0" question.

* Purge of bugs and update/completion of documentation: Here I can 
really get on board. One conception of gretl 2.0 is that it has 
achieved a degree of maturity where we have squashed as many bugs as 
we can find on an extended period of testing, and have documented in 
a reasonably comprehensible and cross-referenced form all that the 
program can do.


More information about the Gretl-devel mailing list