axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nadir Amra <>
Subject RE: Proposal - release versioning and branching model.
Date Wed, 19 Jan 2005 20:49:58 GMT
I think we need to come to a point where we think the public APIs are 
solid.  At that point in time, we should avoid changing the public APIs 
unless absolutely necessary in order to avoid customers having to rebuild 
their applications. 

Changes/enhancements to the engine itself should be OK, and I really do 
not have an opinion whether it should be in a point release or major 
release.  However, I do think we should use point releases in the future 
for fixes, platform support, etc.

But the code base is continuously being enhanced and fixed, so I am not 
sure when would be a good time to go to the release/versioning model.

I do think we are moving through the major releases too fast....but not 
sure what can be done about it.....

"Lilantha Darshana" <> wrote on 01/19/2005 02:22:00 PM:

> According to this comment it seems like you suggest to have a 
> flexible versioning model that aid us changing
> to public interfaces as we wish and would like to do lot more 
> interface changes in most of our releases.
> This mean we do not have a good public API design at our hand at 
> this moment. i.e. even after
> we have released 1.4 of the code. additionally it realize me that we
> need lot more changes in next couple of 
> releases as well. This is a question about maturity of the public API. 
> Even though, this comment say ppl are happy about the model of this 
> public API change. 
> In reality I would say that each time we change our public API 
> anybody who wish to get esp. defect fixes 
> and internal enhancements, need moving to next version and they 
> should *always expect a incompatibility* of 
> the integrated APIs. This should be measured from the perspective of
> resources, time, complexity and cost.
> Consider following example scenario which is realistic:
> if a customer uses 1.a of the axis and they have a webservices 
> running on production server, and they are 
> experiencing problem due to a defects in 1.a of the code. Imaging 
> that resources who originally integrated axis 
> into their product has left the company. Assume that their current 
> development team inquired with apache 
> axis site and have found that this defect has been fixed in 1.b of 
> the code and suggested moving to 1.4. 
> However, assume that in 1.4 we have made some changes to public API 
> as well. This mean that, they need
> changing their code (to reflect new API changes in 1.4) and test 
> this changed code with 1.4 release when
> they move. This also introduce a down time for their production 
> server as well until the defect get fixed. And
> is not a cost effective transition.
> This scenario shows that in reality this is not a happy situation 
> for any one. In contrast if we had a minor+point 
> version, and had that defect fixed in those minor/point version, 
> customer would have seamlessly moved to the 
> defect fixed version and could have gain advantage of the minor 
> enhancement done in the new version without
> even touching their code and just by a configuration change. (of 
> cause with some minor testing)
> Considering above facts and lots of other reasons let me elaborate 
> my proposal little more:
> Major releases signify significant changes to the library and 
> Developers may perform a major release if there have been 
> substantial improvements 
> to the component. Developers must perform a major release whenever 
> the new release 
> is not - at least interface-compatible the previous release. 
> (We can relax on this hard rule little bit, by customizing this 
> according to our need )- 
> This mean clients need lot of code changes for them to use new 
> version. To adhere to this 
> model we need to work on a better/improve our design on public APIs.
> Ideally, when we 
> publish and documents this API we should not change it until at 
> least for the next major 
> version. Although we can discuss this and customize as we wish.
> Minor releases signify enhancements to a component that do not 
> necessitate a major release. 
> Developers may perform a minor release if the release is at least 
> external-interface-compatible 
> with the previous release. In other words, whenever a client depends
> upon at most the external 
> interface of a component with a given minor release, it will work 
> with all subsequent minor releases 
> within that major release. This does not refrain us been releasing 
> new APIs keeping already 
> published APIs intact.
> A point release typically involves simple bug fixes or optimizations
> that do not introduce new features. 
> Developers may perform a point release if the release is at least 
> interface-compatible with the previous 
> release. In other words, whenever a client depends upon a component 
> with a given point release, it 
> will work with all subsequent point releases within that minor release
> Additionally we shall have alpha, beta, rc versions as currently we 
> I haven't heard from others, please provide your thoughts & suggestions?
> regards, 
> -Lilantha 
> -----Original Message-----
> From: John Hawkins []
> Sent: Friday, January 14, 2005 5:11 AM
> To: Apache AXIS C Developers List
> Subject: Re: Proposal - release versioning and branching model.

> I understand your concerns but I don't think we should get too hung 
> up on this. 
> If we look back at previous MINOR releases then it's usually had 
> changes to the API. Thus should of actually been a candidate for a 
> MAJOR release according to the model you are proposing, if I read it
> correctly. Even in this release which was supposed to me a bug fix 
> release (thus a candidate for a POINT release) we have changed the 
> Call interface and changed the names of the dlls as well as creating
> a NEW library model - no small changes ! 
> I think what we're doing now is fine. As long as we make it quite 
> clear, on the WIKI or release notes, what has changed. 
> I think people seem to understand the quality and function of the 
> code we have. 
> -1 to changing what we do now - I think we are correct. 
> John Hawkins

> "Lilantha Darshana" <> 
> 13/01/2005 21:11 
> Please respond to
> "Apache AXIS C Developers List"
> To
> "axis \(E-mail\)" <> 
> cc
> Subject
> Proposal - release versioning and branching model.
> Hi All, 
> I was thinking about the maturity scale of the Axis C++ compare to 
> axis java and others. 
> It seems like we move very fast in our release versioning and does 
> not make much 
> progress on the maturity scale of the project. Now we are going to 
> release version 1.5. 
> However, compare to axis java we are far behind in features, 
> stability etc. in contrast 
> axis java is in its 1.2RC yet. Where it has released it 1.1 on June 
> 16, 2003, and has 
> taken more than 1.5 years for releasing 1.2. (same goes with 1.0) 
> Of cause, axis java is in its 3rd phase since IBM originally hand 
> over it to apache 
> and it has comes a very long way. I hope c++ version of axis can get 
> all the experiences java version under went and can start from there to 
> i.e. learn from experiences. 
> Concerning these things, I would propose of having a process on 
> release versioning. 
> We can learn from other projects how they do it. For an example 
> Jakarta-commons 
> release versioning scheme . 
> and version numbering 
> Where defect fixes and minor changes we release with 'Point' 
> releases and minor enhancement 
> go in Minor versions. API changes, architectural changes go in 
> These enhancements should be categorized and finalized in each 
> version depends on the 
> priority and feasibility. 
> Further to this there should a proper process of selecting cvs 
> branches for each releases. 
> regards, 
> -Lilantha 

View raw message