[Gretl-devel] time for 1.9.8?
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