+1 for stable API. Untill now, we have been doing major changes to the API in every release. I think with 1.5, we have come to a state that we can call the exposed APIs to be fairly stable. Hence, I believe, we could base our future APIs on 1.5. Even if we want to change after 1.5, it is advisable to give a lot of thought on backward compatibility and deprecating before obsoleting.
As far as version numbering goes, well I just dont feel its the right time to discuss this - there are better things to do - like fixing 100+ issues in Jira :) Anyway, we cannot compare a C++ project to a Java project - given the complexities involved in the language itself. Thanks, Samisa... On Wed, 19 Jan 2005 14:49:58 -0600, Nadir Amra <[EMAIL PROTECTED]> wrote: > 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" <[EMAIL PROTECTED]> 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 > infrastructure. > > 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 > have. > > > > > > I haven't heard from others, please provide your thoughts & suggestions? > > regards, > > -Lilantha > > -----Original Message----- > > From: John Hawkins [mailto:[EMAIL PROTECTED] > > 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" <[EMAIL PROTECTED]> > > 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 > Majorversions. > > 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 >
