I've like to propose adding a ROADMAP section to module documentation.

It would be a *short* summary of planned changes for future versions, noting what features would be removed or changed, or upcoming new features that will be added.

More detailed roadmaps should be put in a separate file (e.g. `ROADMAP` or `ROADMAP.md`) that should be referred to in the section. Or link to the roadmap if it's online.

I have been making a lot of changes to Graphics::ColorNames lately. The module has gone too long without any maintenance, and suffered from feature bloat.

Some notable changes that are already on CPAN:

• A switch to semantic versioning, e.g. v3.3.3.
• Some color schemes (Netscape, HTML, Windows) have been moved to separate modules.
• The Netscape and HTML schemes have been deprecated in favor of the WWW scheme.
• The X scheme has been updated to the latest X-Windows colors (which includes the CSS/WWW colors).

Roadmap for the future

I am planning on making the following changes:

• Removing autoloaded method names for colors.

• Removing the (deprecated) tied interface, but putting that in a separate module

• Moving the color schemes into the Graphics::ColorNames::Schemes namespace, but provide an option to use the old namespace.

• Change it to a Moo-based class

• Removing support for Perls < v5.10.

I've created an experimental Type::Tiny library called Type::Const that coerces ArrayRefs and HashRefs into constants using Const::Fast.

Why?

When you have read-only attributes in Moo(se) classes:

has things => ( 
  is => 'ro',
  isa => HashRef,
);

While you can't change what hash reference things refers to, you can change the contents. This is fine:

$obj->things->{$key} = $val;

and there are good reasons for that.

But in other situations, you have built a table of data that you do not want changed. You can use this instead:

has things => ( 
  is         => 'ro',
  isa       => ConstHashRef,
  coerce => 1,
);

The coercion means that any hash reference will be made read-only.