Perl opens the 5.39 development series

Opening a development series changes where new interpreter work can proceed. It does not require a large list of completed language features. The Perl release history records 5.39.0 on June 30 as the start of the 5.39 development track, with Ricardo Signes holding the release responsibility.

The source at that tag makes the transition unusually visible. Its new perldelta file is a template, complete with instructions telling contributors where to describe future changes. Reading those placeholders as shipped capabilities would produce a fictitious feature list. The actual event is the opening of the next line of development.

I value Perl's continued usefulness for short text programs more than a constant supply of new syntax. Even so, the distinction between development and maintenance matters to that preference. Existing programs need compatibility, while interpreter work needs somewhere to explore changes before asking the wider ecosystem to depend on them.

Development and maintenance have different promises

The policy in this source snapshot distinguishes supported stable series from development releases. It explicitly says the project does not provide security updates or bug fixes for development releases. That is a support distinction, not a statement that developers never repair bugs while developing the interpreter.

A numbered development snapshot identifies a particular state that people can examine and test. It is not an undertaking to maintain that exact snapshot as a production branch. Someone adopting it must understand that continuing development is where subsequent changes arrive.

Maintenance branches have a narrower purpose. The policy concentrates them on crashes and serious installation issues, as well as regressions and security problems. Even a useful repair cannot enter a maintenance branch if it violates the unacceptable-change rules. The policy specifically excludes a crash fix that would break binary compatibility.

The two kinds of branch therefore answer different questions. Maintenance asks which corrections can preserve an existing release's contract. Development asks how the interpreter should change, with proposed additions and compatibility decisions still subject to review. Treating the development version as a maintenance update would hide the difference that the project documents.

Changes begin in blead

The contributor guide at this tag calls the main development branch blead. It says changes go there directly, with some patches subsequently backported to maintenance. Contributors who believe a patch belongs in maintenance should explain that case when submitting it.

That ordering gives a correction one development history before maintainers decide whether it also fits a supported branch. It also means a successful patch submission and a maintenance release are distinct events. The maintenance criteria still apply after code exists on the main branch.

The guide asks contributors to describe meaningful changes in perldelta. Its examples include user-visible bug fixes and changes to modules, alongside language changes and significant performance work. The template in 5.39.0 is the place where that explanation can accumulate. It is editorial preparation for the series, not evidence that every listed category already contains a new change.

This matters to people interpreting early snapshots. A blank section does not establish the absence of every internal difference. Equally, a template heading does not establish the presence of a feature. Claims about a particular behavior need the actual implementation or completed documentation for that behavior.

Compatibility still constrains development

Opening a development line does not erase Perl's compatibility policy. The policy discusses how even accidental behavior can become something existing users depend on. Requiring a seemingly small source change across applications can impose a substantial burden when those applications lack complete tests or a reliable automated migration.

The policy therefore asks for a strong justification before removing existing syntax or semantics. It considers how widely the behavior is used and whether affected code can be updated. It also discusses lexical pragmas as a way to make changed behavior explicit while preserving the old behavior by default where appropriate.

Experimental facilities have a different status. The policy permits their behavior to change or the facility to disappear without the normal guarantees. That gives development room to evaluate a design before making a stronger compatibility commitment. An application choosing an experimental feature takes on that documented uncertainty.

I find this an appropriate distinction for a language with so much existing code. New implementation work needs feedback, but a development opening should not imply that every old program must accept a new contract. Explicit experiment status gives authors more information about which assumptions are provisional.

Ecosystem testing supplies different evidence

The contributor guide describes separate testing efforts for the interpreter and for CPAN modules. Interpreter smoke testing exercises source releases across platform configurations. Testing modules against a developing interpreter checks another relationship, namely whether code outside the core still behaves as expected.

Neither kind of result can fully substitute for the other. A core test can exercise an implementation invariant without representing every module's use of the language. A module test can expose an interaction that the interpreter suite did not anticipate. The documented invitation to both efforts recognizes those different sources of evidence.

Perl 5.39.0 provides an identifiable starting point for that work. The release history identifies the development track, while the source supplies the policy and contribution machinery under which it will evolve. Its immediate significance is that contributors and module authors can work against the new series without mistaking that series for a supported maintenance promise.