Deprecation policy

OS support

Rex is able to both run on and manage various operating systems. Supporting all versions of all operating systems ever is an unrealistic goal though. Therefore as a rule of thumb, Rex follows the these ideas to find a balance:

• encourage industry best practices by actively supporting only the OS versions that are still maintained by their upstream
• older OS versions may be supported passively until they start causing problems (e.g. test suite failures)
• unsupported versions should be declared as such in the build system (to help keeping the test results of services like CPAN Testers meaningful and tidy)

If you still need to use Rex with an abandoned OS version for some reason, there are multiple options available:

• use an older version of Rex that still supports it
• contact a commercial support provider to maintain patches for you
• patch Rex on your own

Deprecation of features

Various features of Rex may be superseded by a newer implementation, or may get unmaintainable due to external factors. These functions can be marked as deprecated to raise awareness about this. Deprecated features should:

• output a warning about the deprecation
• suggest alternatives to consider
• keep functioning properly if reasonably possible (but may be OK to fail if it's caused by external factors)

Rex follows the Dotted Semantic Versioning Specification, so a given deprecated feature stays available within the same major version, but may be dropped from the next major version.

Splitting modules out

If a modules is decided to be split out of core, the following workflow could work for that:

1. Ideally start showing warning about the planned splitting upon importing the module.
2. Split out the module into its own repository.
3. Publish it on CPAN with the same or higher version number.
4. Remove it from Rex core, but add the split out version as a dependency.
5. After a grace period with user warnings, drop it as a dependency if needed.