[GRASS-dev] [grass-code I][381] r.colors rules: some scripts broken

[Glynn Clements]

Hamish wrote:

> I am happy for r.colors to evolve, and glad the rules files are now
> finally merged into color=, but fear we will damage tons of user scripts
> with this change.

The longer it's left, the more scripts will be broken by the change. 
It's already been left far too long (if it was originally done in 5.3,
it should have been changed for 6.0.0).

> > As there hasn't been a 6.3.0 release yet, the 6.3 API remains subject
> > to change.
> 
> It is my understanding that module options are frozen for 6.x, not 6.x.y.

That would make the rate of evolution far too slow. It would
essentially mean periods of several years where no real development
can occur.

If that was the case, I would have left after 6.0.0 was released, and
probably have forgotten all about GRASS by the time that 7.x was open
for development.

AIUI, major numbers are for "total" change: 5.x introduced FP and
null. 6.x (originally 5.7) completely changed the source directory
structure (no src/src.contrib/src.nonGPL, no cmd/inter
subdirectories), the build system, and the vector subsystem.

Minor numbers are for incompatible changes, release numbers are for
bug fixes and backward-compatible enhancements.

IOW, analogous to the Linux kernel: 2.0/2.2/2.4/2.6 all have
substantial differences, while all 2.6.x versions are mostly
compatible with each other.

> Would quietly checking for the file in $GISBASE/etc/colors/, after it
> isn't found normally, really hurt much?

Yes.

Either the argument to rules= is a filename or it isn't. If it is a
filename, relative filenames are relative to the current directory. If
it isn't a filename, then it's an arbitrary string, the GUI can't
offer a file browser for it.

-- 
Glynn Clements <glynn at gclements.plus.com>