On 4/17/2017 8:18 AM, Leon Timmermans wrote: > On Sun, Apr 9, 2017 at 4:51 AM, Karl Williamson <public@khwilliamson.com> wrote: >> I think people should be aware of the full consequences of this. >> >> It is not just a simple matter of reverting this patch. Code has marched >> on. In particular, you may recall that I missed some cases where the >> deprecation should have been output, and code to output these was added >> after this patch, and so presumes that these cases are fatal. >> >> If I change the patch to just silently continue, the other code fails to >> output a warning on some of the cases covered by this. If I instead change >> it to output a warning, some cases will have 2 warnings output. And >> cleverness is required to fix that. We could say that at this stage in >> development, that we can live with 2 warnings. But the other warning >> explicitly says it will be made fatal in 5.30. Part of the reason to make >> these cases fatal now, was so that in 5.28, we could implement some of the >> extensions made feasible by this. Having 2 warnings closes the door on that >> possibility. >> >> The solution that requires the least cleverness is my original kludge, to >> simply make >> >> /\${[^\}]*}/ >> >> non-fatal. It's trivial to do this, and keep it to a single warning > > I do think this provides a lesson for the future. It's generally a > better idea to leave breaking changes like this in a revertible state > until the dust has settled down. This is a worthwhile goal, but not really achievable. Such changes should (as this one was) be done very early in the cycle, to flush out problems. At that time, its quite likely that there will be unforeseen changes to come. In this case, the conflict with Autoconf wasn't found until after the freeze.Thread Previous | Thread Next