develooper Front page | perl.perl5.porters | Postings from February 2013

Of versions and variants (was: Perl 7 or Perl 2013?)

Thread Previous | Thread Next
Tim Bunce
February 7, 2013 10:27
Of versions and variants (was: Perl 7 or Perl 2013?)
Message ID:
On Wed, Feb 06, 2013 at 02:44:52PM -0600, Dave Rolsky wrote:
> On Wed, 6 Feb 2013, Ricardo Signes wrote:
> >Furthermore, were Perl 7 to be released (secretly known to be Perl 5.20.0),
> >what would the outcome be?  It would gain attention, and people would say,
> I think the bigger problem is that by not allowing a Perl 7 (or 2013
> or 42), there's no way to offer a new Perl that's an evolution of
> Perl 5. It's Perl 5 the backwards compatible forever language or
> Perl 6 the revolution (which is coming soon?). So if someone had a
> serious proposal for a non backwards-compatible evolution of Perl 5
> (like, say, Moe) they're completely shut out of the Perl name.

> But still, it's hard not to be frustrated when it feels like people
> with a significant interest in the future of Perl 5-like languages
> are told that all future version numbers belong to a project that
> has significantly fewer users, developers, and mindshare than the
> existing Perl 5 language (and community).

I don't understand the logic here. Let's say there are two new variants
of Perl5 that we'll call Moe and Doe. What version numbering would they
use?  Would there be a 5 at the start? Or, if perl6 didn't exist, would
they want to use a 6 to proclaim their new-ness? If both used a 6 would
they be assumed to be related? How would they describe themselves in
relation to the Perl 5 dialect that they're a variant of?

For better or worse the ecosystem we're in, and Moe and Doe and any
other similar projects are in, is the "Perl 5" ecosystem.

And now, for better or worse, that "Perl 5" ecosystem is heading into a
world where there's no longer a simple single chain of sequential releases.

There's much work to be done in preparing our toolchains for this new
world of perl5 variants. For example, having cpantesters work for perl
variants seems critical to me. The name and version of the variant need
to be recorded. I suggest that if we focus on these kinds of simple
practical problems the rest will fall into place fairly easily.

For the record, I'm in favor of the "perl5 version 18" approach.
It's simply a natural way to express the truth of the existing situation.
(Running perl -V:package reports "package='perl5';" and running
perl -V:.*_version reports api_version='18'; and perl_version='18';)

Let's simply talk in terms of "version 18", "version 19" etc.
On the mailing list, in release notes, on conference slides.

However, I don't see any need to go crazy removing the leading 5 from
numbers where it's curently used. That's also expressing the truth of
the existing situation. The versions are versions of perl5.

Now, let's move the discussion on to how we identify variants of perl5
and what needs to change in the perl5 ecosystem to support them.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About