Perl 5.33.0 begins with feature and module metadata

An interpreter version does not fully describe the language settings of a Perl source file. A feature bundle selects behavior within that interpreter, and a separate set of module versions describes its bundled libraries. Perl 5.33.0 begins its development track with changes concentrated in the modules that represent those distinctions. The snapshot is small, but it provides a useful occasion to examine what a version declaration actually promises.

The release notes list two updated modules. feature moves from 1.58 to 1.59, and Module::CoreList moves from 5.20200620 to 5.20200717. The tagged history file dates the release to July 17 and identifies the 5.33 development track. There is no large new language facility documented in this snapshot's delta against 5.32.0.

The notes report approximately 4,300 changed lines across 47 files. They also report only about 69 lines across nine implementation and test files after excluding generated files, documentation, and release tools. Both figures describe the same release under different counting rules. The larger total should not be used to imply a corresponding volume of new interpreter behavior.

Selecting a version also selects a feature bundle

The feature implementation and documentation map version numbers to bundles. In this snapshot, the mappings for 5.32 and 5.33 refer to the same underlying bundle. A new interpreter version therefore does not imply a newly expanded set of implicitly enabled syntax. The mapping is a concrete part of the implementation that can be inspected independently of the release number.

Perl supports explicit feature selection and implicit bundle selection. A program can enable a feature by name, or require a minimum interpreter version and receive its corresponding bundle. These declarations have lexical effects. The behavior they select applies within the relevant source scope, which allows a program to state its assumptions without requiring every file in the process to use identical settings.

use v5.32;
use warnings;
say "the selected bundle includes say";

On this development interpreter, the minimum-version declaration selects the 5.32 bundle. It does not mean that the running binary becomes 5.32, or that every library bundled with that release replaces the libraries installed with the development binary. Language configuration and distribution contents remain separate facts.

The same reference explains that -E enables the running interpreter's feature bundle in the one-liner's main compilation unit. That is convenient for interactive text work. A source file with a version declaration states its intended bundle explicitly, while a one-liner relying on -E follows the interpreter used to invoke it. Those are distinct ways of choosing the initial language environment.

I still reach for Perl for a one-off transformation because the expression often needs little surrounding code. Knowing what -E selects helps keep that convenience precise. A stored script benefits from recording the version assumptions that a command typed once can leave implicit.

Core module history answers a different question

Module::CoreList supplies data about modules distributed with Perl releases. Its implementation at this tag includes lookups by interpreter version and functions for investigating when modules first appeared. This is distribution history, rather than a query for which source file the current process loaded through its library search path.

That difference matters when describing a dependency. Saying a module is in core explains whether a Perl distribution includes it at a particular release. It does not prove that the application has loaded that bundled copy, or that a separately installed version is absent. The metadata supports a packaging decision only when the required module version and the target interpreter are part of the question.

The implementation also distinguishes first_release from first_release_by_date. One orders version identifiers, while the other uses release ordering by date. Providing both functions makes an otherwise hidden ambiguity explicit. The earliest release number satisfying a condition and the first release to ship by calendar date need not be treated as the same query.

An update to this database is useful even when no module interface changes. Tools reasoning about a newly published interpreter need a record of its contents. Without current data, a packaging tool can answer correctly for earlier releases while lacking the information required for the snapshot a maintainer is testing now. This is a metadata dependency of compatibility work, separate from the implementation of a program's text operations.

My preference is to keep those claims separate when evaluating an interpreter update. The feature bundle identifies language behavior selected by source, while CoreList describes historical distribution contents. July's release supplies a dated development interpreter with updates to both modules. Its limited delta is sufficient to begin testing that interpreter without presenting the release as a large set of newly enabled language facilities.