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.