"new" modules will have a metatag "Perl 7"

IMO, that just over-complicates everything.

What would happen with modules that are not packed? That's quite common for private applications, having all the modules (*.pm files) placed in a tree of directories, probably under some VCS. Could I write new modules for that application in Perl 7 while keeping the old ones untouched?

Supporting different Perl versions has been a solved problem for a long time: you just add "use 7" at the beginning of every perl script or module and that activates the specific semantics for that version. It is reliable and minimal.

For those that believe that adding "use 7" is too much boilerplate, think what would happen when the slightly incompatible 7.01 comes out?

For those that believe that adding "use 7" is too much boilerplate, think what would happen when the slightly incompatible 7.01 comes out?

What I took away from the presentation was that “breaking” changes would never be in minor releases like that; and that use feature "unicode_strings" and friends was a pretty big blockage to new features even being known, let alone used; and I agree there. Speaking of which, the only two things I found awful about the presentation were 1) social cop lectures/analysis even though I ended up moving slightly in the direction of their arguments because they were well thought out and 2) opting for “no way!” with regards to default UTF-8 behavior. Given I only had two call-outs on so many huge issues, I should say I’m impressed and hopeful and trying overlook some of the strong similarities to the whole Perl6 transition “plan” that is a part of what you are calling out.

I don't disagree, but what I described was meant to allow old CPAN modules to be installed.

And Dakkar was also only giving an interpretation.

Why don't you join the conference today and ask Todd and Sawyer what their plans are? :)

(I'm wondering too ...)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}