We just spent a painful year deciding that in fact, we're not going to enable strict by default, even though we all wish there was a way we could do that without inconveniencing a lot of people.
So we're not going to break backwards compatibility without a compelling argument. We want to move the language forwards more quickly than we have been, but we'll be sticking with the yearly release schedule, and every year's release should be a safe candidate for /usr/bin/perl.
We saw with Perl 6, that opening up the gates to many changes at the same time is not compatible with a regular release schedule. And as we saw with the transition from Python 2 to 3, no matter how well prepared you think you are, with a large body of deployed code, it's going to take years for all of your users to move over.
We want to make perl a better Perl, not a different language. We're not going to switch to Raku's model for sigils, or change to . instead of ->, for example.
Don't propose changes that go against these principles.
We don't want to discourage wild ideas, just as long as they're wild ideas that feel at least vaguely aligned with Perl's trajectory. If you're not sure, bounce your ideas off someone, or write them up a blog.
So we're not going to break backwards compatibility without a compelling argument. We want to move the language forwards more quickly than we have been, but we'll be sticking with the yearly release schedule, and every year's release should be a safe candidate for /usr/bin/perl.
We saw with Perl 6, that opening up the gates to many changes at the same time is not compatible with a regular release schedule. And as we saw with the transition from Python 2 to 3, no matter how well prepared you think you are, with a large body of deployed code, it's going to take years for all of your users to move over.
We want to make perl a better Perl, not a different language. We're not going to switch to Raku's model for sigils, or change to . instead of ->, for example.
Don't propose changes that go against these principles.
We don't want to discourage wild ideas, just as long as they're wild ideas that feel at least vaguely aligned with Perl's trajectory. If you're not sure, bounce your ideas off someone, or write them up a blog.