Hi Glen,

The release candidate is being promoted to the release tomorrow, and the release date is Dec 9. So unfortunately it is too late to get this into 1.75. (If a critical issue arises that requires a new release candidate, that is a different matter, and we would delay the release accordingly.)

What we can do is put an official patch for Histogram on boost.org/patches and highlight this in the release notes for 1.75.

first of all, sorry that this came so late, but it can't be helped, the bug was discovered late. The question is whether this is a "critical issue", right? I think that getting wrong numerical results in a software that is used in science and industry to make data-based decisions may be considered critical. On the other hand, one could argue that the behaviour that the patch changes was not explicitly specified before - it is now. Nevertheless, numerical results are going to change for clients that used the affected functionality. The bug was discovered by one of my students. It changed some of our scientific results. I cannot decide whether this is critical enough to justify a new release candidate, because that decision has to factor in the costs. From my perspective, not fixing the bug in Histogram means that the wrong behaviour will remain in place for three more months, potentially affecting and angering more users when the behaviour will finally change in 1.76 (assuming that not many (new) users are going to check boost.org/patches). It the cost of delaying the release by a few days, I think it is worth it. If the cost involved is very large, then publishing the patch on http://boost.org/patches is a feasible solution, sure. Best regards, Hans

On 8. Dec 2020, at 15:34, Glen Fernandes wrote:

On Tue, Dec 8, 2020 at 4:53 AM Hans Dembinski wrote:

Was this issue in algorithm::reduce introduced now (i.e. wasn't present in 1.74)? If not, since which Boost release has it been present?

The problem was introduced on Friday Jan 31, 20202, so has been around since Boost-1.73.

...

I cannot decide whether this is critical enough to justify a new release candidate, because that decision has to factor in the costs. From my perspective, not fixing the bug in Histogram means that the wrong behaviour will remain in place for three more months, potentially affecting and angering more users when the behaviour will finally change in 1.76 (assuming that not many (new) users are going to check boost.org/patches). It the cost of delaying the release by a few days, I think it is worth it. If the cost involved is very large, then publishing the patch on http://boost.org/patches is a feasible solution, sure.

Not many users check /patches without encouragement, but users read the release notes and at the very top of the 1.75 release notes would be a warning (emboldened if necessary) to patch Histogram, with a link to the file on /patches

Ok. Many consumers use Boost Histogram through its Python wrapper and we can fix the bug there anyway (the Python wrapper is a separate project not tied to the Boost release cycle).