Re: Release plans: Version 4.4.4 and beyond

[Hans-Bernhard B. <HBB...@t-...>]

On 13.09.2011 23:59, Ethan A Merritt wrote:

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

> - We're still carrying around a bunch of conditional code under the control
>    of --enable-backwards-compatibility.  This could go away.

Or we could put more old syntax we no longer want to support in the 
default under control of the existing switch.  And maybe just drop the 
remainder of the support for stuff that has been in this box since 
version 4.0.

> - The PostScript terminal driver is inconsistent with all other terminal
>    drivers with regard to the "set size" command.

... that's true in no small part only because you bodily removed a good 
number of other drivers that behaved the same way.

> - 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.

Now we're getting somewhere.  That's an externally visible change to the 
main command syntax, and thus would warrant a major version number bump.

> - 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.

That one had me completely puzzled when I (belatedly) saw it mentioned. 
  What was so bad about 'set style line' that its functionality needed 
to be duplicated and incompatibly overloaded onto pre-existing syntax?

Since the addition of 'linecolor' ages ago, 'linetype' already controls 
basically nothing but dashtype.  What would be the benefit of changing 
the name?

It would be a good deal less intrusive to add a new sub-command to 'set 
style' that just turns off the influence of linetype numbers on the 
default(!) line colours.

> - 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?).

I have not the slightest memory of such a discussion ever having taken 
place.  Nor do I see how call might no longer make any sense.

> - 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.

That, along with some of the other plans you brought up, looks like a 
rather good reason to put out a 4.6 release _before_ embarking on that 
journey.  I.e. first make sure we have something to give people who want 
the new features in today's development version, with an official 
version stamp on it, and thus buy ourselves the time to perform major 
reworks that might make things worse for a while, before they get better.

When we find ourselves frequently replying on the newsgroup: "but you 
need the development version for that", that means a new release on the 
trunk is in order.  I think we've reached this point about half a year 
ago.  So it's clear that the 4.4 branch should be ended soon, and 
replaced by a branch starting at the current CVS head.

The question I see as open is whether the changes present in today's 
warrant a 5.0 version number.  Things that are currently just plans 
should not factor into that decision.

> 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?

To the extent such plans are, indeed, known and accepted at the time of 
a 4.6 release, sure.