Re: [Gretl-devel] nasty bug in gretl 1.7.3
Am 10.03.2008 02:02, Allin Cottrell schrieb:
On Sun, 9 Mar 2008, Sven Schreiber wrote:
> 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...
I take your point, but the only such change in current CVS is the
handling of string variables, and that's the main reason why I was
hesitant to base a new release on current CVS without further
discussion.
I thought the "multiply" thing was another such change (but I don't even
know what it is...)
I'm happy to listen to suggestions on a policy for future use.
I could imagine several things:
For example, one could adopt a policy that only releases 1.8, 1.9 etc.
may break existing scripts by design, not minor point releases such as
1.7.4, 1.9.6, etc.
Or, one could say that each code-breaking change must be preceded by a
certain warning period in which the old use is possible but is
considered deprecated. (Similar to what is partly done already.) The
manual could have a section "deprecated commands to disappear in the
future" that would be updated with each release -- that way the
developers also keep track of how long a certain syntax has been
deprecated already. Alternatively (or in addition?) gretl could print
the according warnings in script outputs; although I guess implementing
that is more work than just documenting it.
In principle we could also start another tracker branch on the
sourceforge pages to keep track of the deprecated things. If you want to
go that way I could also be the admin of that, but I'm not sure if it's
really the best way to do it.
I'm sure there are other ways, too.
cheers,
sven