Backport #5025 to release_212 - #5028
Conversation
|
@vicentebolea There were two commits in the original PR, that got merged into master with rebase. This backport PR seems to inherit only the changes from the second commit. |
Yikes! Do we need to re-inspect all the backports? |
no worries, backport applies all the changes from a PR since it uses this command |
|
@pnorbert @eisenhauer the issue is that the backport action expects merge commits as opposed as rebase type of PR. |
…s of the io.AvailableVariables() result map/dictionary. Note: %g in printf and cout << doublevar in C++ renders 6 significant digits by default and a value like 130255.32345 is printed as 130255, looking like an integer. Now we print 1.302553e+05. In case of bpls, min/max for small values (-10000, 10000) are still printed with %g, but outside that they are printed with %e. (cherry picked from commit 828a16b)
(cherry picked from commit e225139)
b9e1b53 to
f681c26
Compare
Hmm. What does that mean in practice? I don't think the original PR looked any different than any other PR. Maybe something else non-conflicting had been merged before it and the branch was out-of-date with master (but still mergable?) |
No, the issue was exactly the merge type (to rebase) I can see that the original PR was merged as a rebase. My bad I did not consider that case. I have checked the other backports and the are all correctly backported (only one rebase but it was a single commit). I will merge this and create the 2.12.1 release tag on the tip of release_212. |
4 participants
Backports #5025