Exploit the versioning (was Re: Backwards compatibility and release 1.0)

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.