You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2006/08/14 20:22:53 UTC

Defining the term "official Derby beta release"

I was going to call a vote to give an official beta designation to the 
10.2.1.0 distriibution availiable at 
http://people.apache.org/~rhillegas/10.2.1.0-beta/. However, I don't 
think that the Derby community has defined what this term means yet. 
Kathey has provided a pointer to the definition of this term used by the 
HTTP Server project: (http://httpd.apache.org/dev/release.html).

For the HTTP Server community, beta designation comes at the end of a 
vetting cycle and involves a community vote: First the community 
determines that the code performs basic tasks. I think this means that 
the Derby community would need to vote on the status of the trunk before 
cutting a release branch and changing the release id from "alpha" to 
"beta". I'm not aware that we have ever done that. Have I missed a step? 
For 10.2, we simply marched toward our goal, announced in advance that 
the branch was imminent, fielded no objections, then cut the branch. Do 
we want to adopt a more formal process like that used by the HTTP Server 
project?

Thanks,
-Rick


Re: Defining the term "official Derby beta release"

Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:

>
>I think the process for the previous Derby releases worked well, don't
>think we need to add any formalility to it. I think a summary would be:
>  - create branch
>  - stablize branch with snapshots
>  - produce release candidate & vote on it
>
>  
>
This covers the development angle,  but what  I think what is needed for 
10.2 and significant feature releases is a beta  that users can identify 
and focus on as a snapshot that has the feature set for the release and 
signifies that it is really time to try it.  I don't think we have to 
have a vote to reach beta status,  like the http project.  I think it 
can be the release manager's call.   I asked for clarification because I 
  was confused by the term "beta candidate".  I think if I were a user, 
I would think, oh this is the beta candidate,  I'll wait for the actual 
beta.  We need user testing now, a beta available for download from the 
website that users will be motivated to try.

 Maybe  finer grained version of  Dan's process would be

 - create branch
 - Create first beta snapshot 
 - stabilize branch with additional beta snapshots 
 - produce release candidate & vote on it


Kathey







Re: Defining the term "official Derby beta release"

Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:

> I was going to call a vote to give an official beta designation to the
> 10.2.1.0 distriibution availiable at
> http://people.apache.org/~rhillegas/10.2.1.0-beta/. However, I don't
> think that the Derby community has defined what this term means yet.
> Kathey has provided a pointer to the definition of this term used by the
> HTTP Server project: (http://httpd.apache.org/dev/release.html).
> 
> For the HTTP Server community, beta designation comes at the end of a
> vetting cycle and involves a community vote: First the community
> determines that the code performs basic tasks. I think this means that
> the Derby community would need to vote on the status of the trunk before
> cutting a release branch and changing the release id from "alpha" to
> "beta". I'm not aware that we have ever done that. Have I missed a step?
> For 10.2, we simply marched toward our goal, announced in advance that
> the branch was imminent, fielded no objections, then cut the branch. Do
> we want to adopt a more formal process like that used by the HTTP Server
> project?

We want to adopt our own process for the details of alpha/beta/ga, and
learn from the other apache projects. The HTTP server release page lays
out some good general guidelines that go across all projects:
   - release manager is in charge
   - cannot stop devlopment
   - can have multiple competing releases
   - etc. etc.

I think the process for the previous Derby releases worked well, don't
think we need to add any formalility to it. I think a summary would be:
  - create branch
  - stablize branch with snapshots
  - produce release candidate & vote on it

Dan.