On 9/23/2014 9:12 PM, Vladimir Panteleev wrote:
On Wednesday, 24 September 2014 at 04:00:06 UTC, Walter Bright wrote:
On 9/22/2014 10:16 AM, luminousone wrote:
What is needed?
The people who maintain large projects need to try them out with the beta
compilers and file any regressions.
Question: What's the point of testing betas if the release will occur even with
known regressions?
Framing the question that way implies that all regressions are equally
deleterious. But this isn't true at all - some regressions are disastrous, some
are just minor nits. Delaying the release has its costs, too, as it may fix a
number of serious problems.
It's a balancing act.
We shouldn't hamstring our ability to do what is best by conforming to arbitrary
rules whether they are right or wrong for the circumstances.
Blocking a pull being merged would be much more efficient
than dealing with a pull merged long ago that by release time is difficult to
revert.
Sure. I would block pulls that produce known regressions. The earlier
regressions are known the better. But it is a bit unreasonable to expect large
project maintainers to rebuild and check for bugs every day. It's why we have a
beta test program.
