Hi all,
As you probably noticed a2 release proposal "failed" early.
I first tagged "r400018" as a2 candidate, then we found a Javamail 1.4
regression, fixed it and tagged r400140 for release.
Starting new refactoring work I found out a new bug in the
MimeMessageWrapper/CopyOnWriteProxy things.
A little history of that bug is here:
http://issues.apache.org/jira/browse/JAMES-474
The commits involved in the fix are:
r404802 - Few more tests (work in progress) for NPE and IOExceptions in
message cloning/sharing code (JAMES-474)
r404787 - Added one level of indirection (field=>getter) over the
wrapped message. Now the wrapped message is kept inside the
referencetracker (more clean, easier to read)
r404783 - Previous commit was not a solution, trying a new one after a
new failing test has been added (JAMES-474)
r404782 - One more test for the MMCoW object (still investigating on
JAMES-474)
r404780 - Possible fix for an NPE whose test has been just added to
MimeMessageCopyOnWriteProxy (maybe related to JAMES-474)
r404779 - Further changes to MimeMessageCopyOnWriteTest to better check
the expected behaviour and to avoid leaving garbage in the temp folder.
r404773 - Refactored the MimeMessageCopyOnWriteProxyTest and added a
proof of a bug (maybe related to JAMES-474)
How do you prefer to proceed?
a. Should we branch from r400140, merge the above changes and try an
"a3" release?
From there the only known showstopper is JAMES-490:
http://issues.apache.org/jira/browse/JAMES-490
I already solved this for a SocketFactory I use in a custom
remotedelivery implementation and it seems to work, so I'll commit a fix
soon.
b. Should we otherwise try to release as alpha3 the current trunk as
soon as JAMES-490 will be fixed? This time I would identify the "stable"
revision, run a build of that revision and publish it on my apache home
for people to test, if no showstoppers arise I'll tag it as alpha3 and
ask Noel to prepare the release and start the vote.
Imho it does not make much sense to "branch" for alpha releases so I
would go for the latter solution, but I understand that you may have
different opinions.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
