commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Release Process for Sandbox Projects
Date Sun, 24 Aug 2003 15:33:38 GMT
the usual rule is that sandbox components cannot be released. this has 
worked very well in the past and i'd be very reluctant to see exceptions 
without compelling reasons.

commons-attributes has a nightly build which are often used as SNAPSHOTs.

putting commons-attributes in a state where it *can* be released is an 
important stage in gaining promotion. momentum is also an important factor.
  commons components are small and so communities don't need to be as large 
as for more ambitious products.

there are a couple of simple things that have worked for components in the 
past. the first is sorting out the documentation and the web site. the 
attributes web sites hasn't been updated for almost a year and doesn't 
contain a lot of information. the second is putting something into the 
apache newsletter.

- robert

On Sunday, August 24, 2003, at 03:21 PM, Leo Sutic wrote:

>> 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.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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message