small typo correction see below (i.e. 1.4 should be
1.b)
regards,
-Lilantha
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.b .
However, assume that in 1.b
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.b ) and test this changed code with 1.b 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
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 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
