Hi Jochen
1) the website upgrade is easy
2) If you don't mind I would stay clear of bundling the JARs - I can add a goal to the Maven build to copy all dependent JARs into a directory and I can also provide the same magic using ANT (with a little bit more work ouf course but there was reason why Maven was invented)
3) XMLRPC-58 (wring bug reporting address) I have it already fixed but need to commit
4) I hate to say it but for we need JUnit tests for applied patches. I have no intention to run an OS project differently from my commercial projects ... ;-)
It seems that I have some time tonight (I have to tell my girlfriend though) to do 1) to 3)
Cheers,
Siegfried Goeschl
Jochen Wiedmann wrote:
Hi,
it seems to me to be common sense, that the current tree is almost ready for 2.0. This RFC should help to give a reply to "What's missing?", "Who does it?" and to the details.
This posting is also available at
http://wiki.apache.org/ws/XML-RPC/2.0ReleasePlan
1.) What's missing?
I'll list below, what I'd personally see. I suggest that an item should only be allowed to enter the list, if there's a volunteer stepping forward:
Task Volunteer
Website Upgrade spoeschl? (As far as I know,
you already did most of the
work?)
Upgrade to commons-httpclient 3.0 jochen Add prerequisite jar files to CVS jochen and distribution (Suggestion) Support for gzip compression hgomez
Remaining questions: What else? Is adding prerequisite jar files ok? I
personally would support it, because it simplifies the use of XML-RPC
and all prerequisites are either under ASL (commons-codec,
commons-httpclient, servlet-api) or CPL (junit).
2.) Open Bugs
I am ignoring bugs, which have been entered before 2004-Jan-1 and bugs with priority normal or less. That leaves
XMLRPC-56 An asynchronous callback object that manages timeouts
XMLRPC-57 Unreleased version XMLRPC_1_2_B2
XMLRPC-58 Incorrect bugreporting address
XMLRPC-59 Missing directories in currently released tarball
All of which either don't apply to 2.0 (XMLRPC-57) or aren't sufficiently serious, IMO.
Questions: Any other bugs we should consider?
3.) Release plan
- Release 2.0 beta is created after the above task list is completed. - Release 2.0 is created four weeks later, if there are no serious bug reports. A bug report (Jira!) is considered serious, if any committer declares it serious. (How? Set a keyword in Jira?) - If there are serios errors, a version 2.0 RC 1 is created two weeks, after all serious bug reports are closed. Version 2.0 is created two weeks later, if there are no serious bugs. Otherwise, 2.0 RC2, ... is required and the schedule is delayed in the same manner. - A maintenance branch r2_0 is created with the release of version 2.0. The branch is dedicated for bug fixing and releases 2.0.1, ..., if any.
Questions: Is the above too simple? Do we need separate votes for rc's or the final version? Anyone volunteering to do the releases? If no one else does, I'll do. (Need to create a JaxMe release anyways, so it seems half the work.)
Jochen
