Vladimir Prus wrote:
Fernando Cacciola wrote:
Fernando Cacciola wrote:
I can test it with gcc (4.4.1) in a Debian Linux Box, but not today (8pm already here). And probably not until next Monday.
OK. I just did it, and it also works with gcc 4.4.1
I'm certainly missing something. Clearly, the change you committed right before freeze changed a finite amount of files. What's wrong with reverting those files into the state they had immediately before your commit?
While "I really hated the idea of going back to 2 headers" might be a good technical argument at a different time, do we really want to spend time trying yet another alternative solution at this point?
If it were just a matter of reverting N files to a previous version I would just do it. But it isn't.
I need to revert 2 files, BUT ALSO
1.Manually edit-back "optional.hpp", which included "none_t.hpp" but now includes "none.hpp"
If it included none_t.hpp and now includes none.hpp, it means there was a commit which changed that file. How about reverting that commit?
That would revert all the other changes to "optional.hpp" (which is the bulk of the update and I definitely won't roll-back).
2.Manually edit-back those test files which included "none.hpp" explicitly and now they doesn't.
Why? Weren't those file changed as part of some commit?
Yes, a commit that involved other changes that I don't want to roll-back.
3.Manually re-edit the documentation to state that "none.hpp" must be included separately.
Again, I'm lost. I presume there was commit which made documentation no longer say that none.hpp must be included separately.
Sort of. The doc commit introduced all the updates to optional, including "none" documentation which was entirely non-existing before. As you can see now, the problem is that the problematic commit did not involve just "none" but a lot of other changes.
Granted, I can avoid 1,2 and 3 there by going back to the 2 headers but keeping "optional.hpp" updated, that is, including "none.hpp". But that renders the point of having two separate headers totally useless.
I totally understand that doing a last minute fix which delays the release even longer is annoying, but IMHO is even more annoying to release something knowing it has a problem just because we don't want to spend a few additional days clearing up anything that may leak after the fix. I'm afraid that's just the way our industry works, but I don't but like it.
Also, unlike the problematic in-a-rush fix that caused the problem before, I've given this fix a lot of attention, and it comes with a test, so I could tested it locally on 3 different platforms and I will test it on a fourth today.
And finally, Thomas is off until Wednesday anyway, so what's the point in rushing just now when we can do whatever it takes to make sure this fix will really work?
Well, technically Thomas said it's OK to either revert, or apply Richard's patch. You seem to propose checking it some different patch.
If you look at it you'll see is only marginally different.
Assuming you post it now, and Thomas OKs it on Wednesday, and there are no issues, we've lost 2 days compared to reverting today. And delays tend to add up.
Why 'lost'? To me we gained two days to make sure the patch works.
I don't have no authority to tell you what to do; if you feel that whatever patch you have now is OK, you should post it and wait for Thomas to comment.
I already posted it 4 days ago, and asked everyone in this thread to test it if they can. The bottom line is that I'm pretty confident this patch will work. It's the same patch Richard proposed (go look at it and you'll see that, even if not token-by-token, it is the same), I used a specific test-case, and the test case passed the tests in 3 platforms. Best Fernando