> From: Robert Leland [mailto:rleland@apache.org]
>
> It avoids the stigma that comes with the label Alpha.
That is an option, but I personally prefer the alpha -> beta ->
release candidate -> big one naming scheme. Since commons
attributes had reached 0.8 or so before I got involved I'm
going to call my version 2.0. Otherwise you have the stigma of
version numbers not only seemingly never reaching that .0 release,
but actually *going backwards*!
I can't really call it 1.4 since that implies some compile-time
compatibility with all 1.x versions, of which there are none.
> Also I believe it
> also avoids the version inflation that happens, version 1.0 -
> 3.0 in 6 months or less.
If I understand the naming correctly then you have this:
Major.Minor.patch:
Major number: If this changes, you have in essence a completely new
package - no compatibility is guaranteed at all.
Minor number: Recompilation may be needed. (Source compatibility with
versions with same major number.)
Patch: Binary & source compatible with same major.minor version.
So version inflation would only happen if I during six months push
out 3 completely incompatible versions, in which case I think I'd:
a) be able to finally shake off any community that could have
attached itself to my project
b) start finding it hard to get the +1 votes required for release
c) really start thinking about what I'm doing.
/LS
|