I have a proposal.
Unlike with say the GLR, perhaps this whole :D thing may be a good test case for
the Perl 6 feature of explicit language versioning.
How about we don't make the :D change now, and give more thought as to whether
we actually want to do it at all.
If we do decide it is worthwhile, lets make it so that the :D change is part of
Perl 6.1 say, along with any other changes we decide in the near future would be
a good idea.
Then, programs that explicitly say "use 6.1" or such will get :D as default,
while those that don't or say "use 6.0" etc will get the current behavior with
:D not being default.
I say, save any further major breaking changes before this Christmas for things
that would be really hard to change later and are sure to be worthwhile now, and
the :D thing is not one of those.
What do you think?
-- Darren Duncan
On 2015-10-14 2:54 AM, Moritz Lenz wrote:
So a large percentage of the module updates are done by group of maybe five to a
dozen volunteers. So, do the math: 5 people updating 70% of 390 modules. Modules
they are usually not all that familiar with, and usually don't have direct
access. So they need to go through the pull request dance, waiting for reaction
from the maintainer. In short, it sucks.
The ecosystem hasn't yet fully recovered from the s/done/done-testing/ change,
nor from the GLR, nor from the need to prefix 'unit' to some declarations.
And this is why I'm getting increasingly frustrated and angry when people
propose major breaking changes, brushing off the implications for the ecosystem
and its maintainers with "but it's not 6.0", "shouldn't be a problem", "we
aren't stable yet".
We want to release Perl 6 by Christmas, and it'll reflect *very* badly on us and
the language if many modules in the ecosystem are broken. And any change that
requires us to touch all .pm files will result in that.