commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <>
Subject RE: Release Process for Sandbox Projects
Date Sun, 24 Aug 2003 14:21:06 GMT

> From: Robert Leland [] 
> 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 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.


View raw message