axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <HAWKI...@uk.ibm.com>
Subject Re: Proposal - release versioning and branching model.
Date Fri, 14 Jan 2005 10:11:07 GMT
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" <ldarshana@edocs.com> 
13/01/2005 21:11
Please respond to
"Apache AXIS C Developers List"


To
"axis \(E-mail\)" <axis-c-dev@ws.apache.org>
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 
grow. 
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 . 
http://jakarta.apache.org/commons/releases/versioning.html 
and version numbering 
    MAJOR.MINOR.POINT 
Where defect fixes and minor changes we release with 'Point' releases and 
minor enhancement 
go in Minor versions. API changes, architectural changes go in Major 
versions. 
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 

Mime
View raw message