Front page | perl.perl5.porters |
Postings from February 2013
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. Tim.Thread Previous | Thread Next