version

[Daniel J S. <dan...@ie...>]

  >

>
>***
>
>This discussion takes us to new dimensions of gnuplot -- and the end of year
>is almost here ...  thus I would propose the following:
>
>- add this command "raise" as I proposed, with a simple X11 implementation
>as proposed
>

I could write a patch this weekend some time.

>- release gnuplot 3.8k next week, and gnuplot 4.0 in January
>

I would say that the "raise" isn't essential to a release.  It could 
remain as a patch.  Since it will likely be a small patch, my guess is 
that it won't be as susceptible to changes in CVS and won't need 
updating so much.

But certainly, moving toward a 4.0 release is a good idea.  (If I 
understand correctly, 4.0 will be an "official" release, not a beta sort 
of thing.)

>- do all these nice interactive terminal changes afterwards, with enough
>time for discussions
>

Well, I guess this was my idea.  But I myself am not totally sold on 
this.  Doing this is sort of a big change, or addition, to the paradigm, 
and I'm afraid that it may take things down a path of people requesting 
additional support, and soon we have something that is more than 
intended and perhaps totally different from a better scheme.  (Maybe the 
scheme Hans discussed where there are multiple plots.**)  I guess it is 
the syntax that is really the "standard" in Gnuplot [Changing things 
behind the scenes isn't always so crucial... "ignore that man behind the 
curtain" ;)], and 'raise' seems the logical choice.  But still.  I see 
the beta releases as being ways of putting those patches that are 
clearly desirable into the code then allowing developers to try them 
out, suggest changes and knock the rough edges off of them.  [Case in 
point is the image patch.  Having Petr's and Ethan's feedback has made 
it much nicer than what I originally did.]  I would say aim for 4.0, tag 
the version, then start introducing some of the new ideas and let things 
destabilize a bit.

Dan

** But that is a BIG change.  It would require saving the actual plot 
commands in a linked list, not too bad.  But also it would require the 
capturing of the state of the system "set variables" before any change 
in the terminal window.  I assume that would mean organizing all those 
variables into a nice table format.