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"
<[EMAIL PROTECTED]>
13/01/2005 21:11
|
|
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
