Hi, sorry if I missed an earlier posting (and I can't go and look at the archives 'cos the link is still broken) but where did you get that list of bugs from? It doesn't match the ones I see if I follow the link from the issues page http://ws.apache.org/xmlrpc/issue-tracking.html.

Thanks,

Dave

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







Reply via email to