Front page | perl.perl5.porters |
Postings from August 2011
We've gone around on this issue before, and I don't believe we've settled it. So I'm trying again, this time I believe I have more clarity. I believe that a patch should be deemed considerable for a dot release if it fixes a bug that was introduced somewhere in its major release cycle. So, something that was broken in 5.14.0 should be fixable in 5.14.1, 5.14.2, etc. The effective difference between this wording and the current one is that it allows bugs in new features to be fixed without having to wait until the next even-numbered release. There was some bemoaning on this list a while back that we don't seem to get people using new features much until a major release or two after they first appear, and the original developers have moved on to something else, and aren't available to fix things. I maintain that our current policy promotes this hesitation to try things out, because the conventional wisdom is to avoid a .0 release of any product, and our policy effectively means that the whole major series is a .0 release for new features. If there is a new feature that is going to make my life better, but I know that it is a .0 release, and that it's going to be a year before any bugs in it will be fixed, I'm going to be leery of using it. I'd be willing to experiment more if there's a release scheduled a month or three away. I claim that the current policy is shooting ourselves in the foot. It encourages lower quality by discouraging usage of new features in the field, with the consequent effect that the developers who made them think the quality is higher than it is, and they get bored and move to something else, and even if they are available years down the road, have forgotten a lot about the implementation. It shouts out, "We don't service what we build, at least not for a long long time."Thread Next