TL;DR

A couple thoughts about Perl 7.

NOTE the link to Perl 7 is to a post by R. Signes on the Perl Steering Commitee. Probably not the best link to put, but it’s what got me think about it.

I’ve never been involved with Perl development. Maybe I tried to send a few documentation patches that got rejected, which of course was wrong 😝

So, I can offer the point of view of one:

• amateur (little projects, mostly for personal or side-work stuff);
• eager to remain adequately educated (reading about the good and the bad sides of things);
• enthusiast (it’s fun!!!)

user of Perl (5).

The Principle of Least Surprise

The Principle of Least Surprise more or less guides us to do stuff (like taking a design decision) that will not confuse people. If all stable releases of Perl have an even minor version, we would be much surprised if version 5.35 ever became something for general use (beyond the fact that the versioning approach is stated clearly).

I skimmed through some of the discussions on Perl 7 but didn’t see it cited explicitly. I hope this is because it’s so much ingrained in people’s minds that it’s not necessary to put it on the table.

Anyway, this brings us to the following topic.

Semantic Versioning

Semantic Versioning 2.0.0 has the following summary:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

I’m not sure whether Perl 5 stuck to this rule so far, but I’m inclined to say no because the deprecations did not end up with a major version bump eventually.

Anyway, Perl 5 somehow adopted a looser version of this approach, striving to keep as much backwards compatibility as possible, at the expense of ease of evolution. I think that R. Signes’s post makes it very clear.

Which means: when that “5” is changed to something else, something big is happening.

Putting this together

If the community/steering commitee/whatever wants to go towards a new version of the more “classical” Perl I’m fine.

If you have to make changes that break compatibility with the past, please do them at the very beginning. Having Perl 7 be the same as Perl 5, but with different defaults, means that you’re confusing people now (a major version upgrade where nothing really changes under the hood?!?) and you’re going to confuse people later (Perl 7.2 broke my code base that was working perfectly with Perl 7.0!).

Unless, of course, you’re planning to go for Perl 8 rather soon and this Perl 7 stuff is only a pivot.

I know that about 15 years of Perl 6 design now put some pressure on Perl 7 to happen fast, but that was an exceptionally big whale and it still takes about 9 months (on average) to deliver a child. So please, take your time and don’t end up in a doubly-confusing situation.

JAPH