gnuplot-beta

Release 5.2.1

[sfeam <sf...@us...>]

I have uploaded a tarball gnuplot-5.2.1.tar.gz to the usual SourceForge 
distribution site.

   https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.1/ 

This is a bit early for an incremental release but I want to put it out now
for two reasons.  

A cluster of related regressions were reported for the 5.2.0 handling of
log-scaled  axis ranges and tic generation.  I consider this regression
to be serious and worth repairing sooner rather than later.

It is not clear when the cvs->git conversion process will settle down to
the point where I am comfortable preparing an incremental release
from the new git repository.  Rather than waiting for that, I would rather
package up 5.2.1 from a final cvs snapshot plus a couple of last-minute
fixes that I will maintain on the side until the git conversion completes.

The list of changes between 5.2.0 and 5.2.1 includes

* NEW set table separator {tab|comma|"char"} allows creation of csv files
* NEW hotkey for changing azimuth in 3D plots with mousing
* NEW splot ... with lines title at {beg|end}
* NEW Rework gstrptime() to handle relative time formats tH tM tS
* NEW command "set rgbmax <value>" controls interpretation of input RGB values
* FIX allow mixed use of in-key plot titles and manually placed titles
* FIX prevent runaway iterations of the form   plot for [i=start:*] ...
* FIX handle in-line range limits for linked or nonlinear axes
* FIX restore pre-5.2 interpretation of logscaled tic increment as a multiplier
* FIX logscale tic placement is closer to that of versions before 5.2.0
* FIX recheck inrange/outrange points after spline or bezier smoothing
* FIX autoscaling of plots with linked axes where data is plotted on x2 or y2
* FIX sampling on x2 if linked to x1;  e.g. plot sample [t=1:5:1] '+' axes x2y1
* FIX empty range on logscale y axis is handled by auto-extending the range

More information in the ChangeLog.

	happy gnuplotting,

		Ethan

Re: Release 5.2.1

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

On 10/28/2017 02:17 PM, sfeam via gnuplot-beta wrote:

> It is not clear when the cvs->git conversion process will settle down to
> the point where I am comfortable preparing an incremental release
> from the new git repository.  Rather than waiting for that, I would rather
> package up 5.2.1 from a final cvs snapshot plus a couple of last-minute
> fixes that I will maintain on the side until the git conversion completes.

Updating CVS is fine, as the ./reconvert script gathers the latest 
version of the code.  Don't want to make the first thing you do under 
git be a release.

Dan

Re: Release 5.2.1

[Ethan A M. <sf...@us...>]

On Monday, October 30, 2017 12:30:22 PM PDT Daniel J Sebald wrote:
> On 10/28/2017 02:17 PM, sfeam via gnuplot-beta wrote:
> > It is not clear when the cvs->git conversion process will settle down
> > to
> > the point where I am comfortable preparing an incremental release
> > from the new git repository.  Rather than waiting for that, I would
> > rather package up 5.2.1 from a final cvs snapshot plus a couple of
> > last-minute fixes that I will maintain on the side until the git
> > conversion completes.

> Updating CVS is fine, as the ./reconvert script gathers the latest
> version of the code.  

I wish someone had made that clear earlier.  
I asked about a freeze and thought that the response was "yes,
a freeze would be good".   OK, I'll go ahead and commit the 10-12
changesets that I applied locally to prepare the 5.2.1 tarball.

Maybe then it should be repackaged as 5.2.2?   There has been 
at least one request for a fix-to-the-fix since I packaged up 5.2.1. 

> Don't want to make the first thing you do under git be a release.

Exactly.  Also I worry that we may turn up additional glitches in the
conversion once serious develoment resumes.

	Ethan

> 
> Dan