axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <>
Subject 1.4 release
Date Thu, 30 Sep 2004 12:25:35 GMT

Hi Folks,

Big note coming up !

I would like to propose some features that we should put into 1.4. I would
like to know what everyone is thinking is useful to have in the 1.4 release
and this small list should act as a starter.

C support -
      firstly define feasibility of making a 100% C++ engine and design,
then (if feasible) implement.
      We will temporarily remove C support in 1.4 to be replaced in 1.5
with new wrapper.

Apache Builds -
      This item is all about getting a daily build. We must also create all
the relevant web pages so it's usable.
      We will build the client first then the server.

Refactor WSDL2WS -
      As it says ! This is a pretty much open-ended item so we do as much
as we can. Remember - at this point we have no C support so anything we can
do here to make that easier to reimplement C in 1.5 is good !

Test documentation -
      document the handler mechanism and other test related stuff we have.

AND - A Quick overview of 1.5 work
C support -
      put back into WSDL2 WS C wrappers for the new 100% C++ engine

Purify and fix -
      As it says - run Rational purify and tackle issues that come out of

Improve HTTP Support.
      Fix outstanding issues with HTTP support in the new transport layer.
There is a lot we can do here and we haven't really defined what it highest

      User documentation and CVS based documentation. including sample can
be improved

With the resource that we have here - we can contain all the above 1.4
items within a 24th November Time-schedule. I would like to propose that we
try to maintain this shorter time-line for releases. That way we keep new
function to a minimum and therefore maintain stability within builds.

I would also like to propose that we move away from our current waterfall
model of code then test. When we have daily builds we can see immediately
what has broken and this will help us tremedously. The more we automate our
testing the better. The one issue with this is that the daily builds will
only cover certain compilation options (as discussed in previous mails).
The test-cycle now appears to consist of running the same tests on
different configurations - is this true? In which case I would ask that
someone find the time to automate those configurations and run them daily
as well?

Please can you feedback your thoughts and ideas on what we should put into
1.4 and what you would like to see in 1.4 We can then make a judgement as
to what the final goal is to be.

many thanks,

John Hawkins

View raw message