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