Re: Release plans: Version 4.4.4 and beyond

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

On Tuesday, September 13, 2011 05:54:07 am Hans-Bernhard Bröker wrote:
> On 12.09.2011 05:50, sfeam (Ethan Merritt) wrote:
> 
> > The chief arguments I see for bumping the version to 5
> > (rather than 4.6):
> >
> > 1) The code in the development branch has diverged enough from the
> > code in the version 4 branch that most new patches cannot be easily
> > back-ported.
> 
> > 2) There are significant syntax and UI changes already in or queued for
> > the development branch [...]
> 
> I consider those good reasons to make a new non-patchlevel release, but 
> I don't see the case for a major version number step.  Those should IMHO 
> be reserved for user-visible, _incomptabible_ changes.  I.e. as long as 
> basically all scripts written for version 4.0 (or maybe 4.4) still work, 
> I don't quite see a reason to bump to 5.0.

So then let's ask the question "Are there changes we held off from
making because they would break backwards compatibility?"

I can think of several.

- We're still carrying around a bunch of conditional code under the control
  of --enable-backwards-compatibility.  This could go away.  I don't know
  a good way to find out how many people use this configuration option, but
  it isn't enabled in the linux distro packages I looked at.

- The PostScript terminal driver is inconsistent with all other terminal
  drivers with regard to the "set size" command.  Also it causes confusion
  that the font size in "eps" output is only half what the user requests.
  The "fontscale" option was a messy attempt to paper this over, but it
  causes additional confusion (if in fact people even realize it exists).  
  Oh, and the sequence of dash patterns in post.trm is different from
  all others.  Why on earth isn't linetype 1 a solid line????
  We could bring post.trm into better agreement with the newer terminals.

- The binary input code needs to be rewritten, if not replaced, and the
  revised version may well not be able to fully maintain the original
  syntax.  It would be nice, for example, if the options controlling
  matrix/array input for ascii and binary files were consistent rather
  than re-using the same keywords for conflicting purposes.

- The introduction of command line macros (./configure --enable-macros)
  was an early attempt to support string substitution.  I believe it
  offers no functionality that isn't better handled using string functions.
  We could get rid of this conditional code.

- The pieces are in place to support "dashtype" as a line property.
  The current syntax overloads "linetype" to mean a combination of dash
  properties, color properties, and width.   Version 5 would be a great
  opportunity to clean this up and support a real "dashtype" property,
  but it would break old scripts that assume line color and dash pattern
  are really the same thing.

- The "call" command no longer makes any sense, and arguably is broken.
  (I can't find the discussion we had about this, but it must have been
  about 2 years ago?).  Let's get rid of it.

- The alpha-channel representation of transparency used by "set style fill"
  and by plot style "with rgbalpha" are inconsistent.  I'll accept the
  blame for this.  Anyhow, I've held off work on supporting a general
  rgba color mode  ( e.g. plot ... linecolor rgba "#3FAABBCC" ) because
  of the inconsistency.  Easy enough to change the interpretation of
  "set style fill transparent ...", but it would invert the meaning of
  existing scripts.

If we do go with a 4.6 release rather than 5.0, maybe these and other 
potential areas should be prominently marked DEPRECATED or MAY CHANGE?

		Ethan