You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Apache Wiki <wi...@apache.org> on 2005/04/11 22:10:47 UTC

[Ws Wiki] Update of "XML-RPC/2.0ReleasePlan" by JochenWiedmann

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by JochenWiedmann:
http://wiki.apache.org/ws/XML-RPC/2%2e0ReleasePlan

New page:
= RFC: Release Plan XML-RPC 2.0 =

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.

== 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 and distribution (Suggestion)||jochen||
||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).


== 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?

== 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.)