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