Re: [Gretl-devel] time for 1.9.8?

On Wed, 22 Feb 2012, Riccardo (Jack) Lucchetti wrote: 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. Allin