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) | *
George_Kasica@??? or Kasica_Pager@???
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 <exim-users@???>
To:
George Kasica <George_Kasica@???>
Cc:
exim-users@???
Date:
01/26/2011 01:25 PM
Subject:
Re: [exim] When can we expect to see 4.75
Sent by:
exim-users-bounces@???
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/
