Phil: Normally I do test the RCs but was out last week and didn't see them come out as they were out rather quickly between RC and release here.
Do you expect another 4.75-RC before 4.75-Release I'd be happy to test on RHEL4 here and report results if you like. George _______________________________________ George R. Kasica | Systems Analyst – Technical Services | Mortgage Guaranty Insurance Corporation 270 E. Kilbourn Ave. | Milwaukee, WI 53202 USA | ( 1.414.347.6491(work) 1.414.732.8503 (cell) | 7 1.888.601.4440 or 1.414.347.2601 (fax) | * [email protected] or [email protected] P Please consider the environment before printing this email. This message is intended for use only by the person(s) addressed above and may contain privileged and confidential information. Disclosure or use of this message by any other person is strictly prohibited. If this message is received in error, please notify the sender immediately and delete this message. From: Phil Pennock <[email protected]> To: George Kasica <[email protected]> Cc: [email protected] Date: 01/26/2011 01:25 PM Subject: Re: [exim] When can we expect to see 4.75 Sent by: [email protected] On 2011-01-26 at 10:07 -0600, George Kasica wrote: > Based on the 4.747 issue with PCRE_PRERELEASE and RHEL4 how soon can we > expect to see 4.75 come out? Curious as I have about half a dozen boxes > here that I need to update to keep info sec happy that are currently stuck > with that issue at 4.73.... If you want to build now, it's a *very* trivial source change. Edit src/exim.c and remove the PCRE_PRERELEASE macro. See: http://git.exim.org/exim.git/blobdiff_plain/88d5edb00796448347da8544088b0db1f9b61ddf..aa097c4c00f62487128d74f65c521f9e877b184f:/src/src/exim.c May I suggest that if you have a fleet of boxes, you consider testing a "Release Candidate" in future? If nobody with your OS tests a Release Candidate, then problems of compatibility with your OS will arise. Exim is maintained by a community of volunteers and those intersecting communities who don't step up to ensure compatibility will have more troubles than those communities that do work with us. It looks like the dynamic module addition is causing various issues; some inherent, in this particular case because I decided that anything where one binary is loading other code into its address-space absolutely had to support reporting version numbers to keep our lives from becoming an absolute hell when people insist they've upgraded Exim but haven't installed the modules and things fall out of sync -- the code is bound to end up used by non-packagers, despite being intended for packagers, so in this broader environment we need better diagnostics. As part of this, I made Exim report compile-time vs run-time library versions for all the main libraries I could test against (so not, eg, Oracle). You can see this with: exim -d --version So, since very few people tested the Release Candidate, it seems that 4.74 is having to serve as a pseudo release-candidate. This is sub-optimal, but it's the reality we're faced with. I can't speak for the other Exim maintainers, but my inclination is that we should give it a week or so to shake out all the bugs that people haven't yet reported, then do 4.75. The RHEL fix is trivial enough to apply as a build patch that I don't see a major issue here. Based on the reports so far, *I'm* not willing to volunteer my time to push out a 4.75 release sooner than that. And I'm not willing to restrict 4.75 to be bug-fixes-only -- there's one feature improvement from the DCC maintainer which I've promised I'll commit to tree, now that 4.74 is out. -Phil -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/ -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
