On Thu, 4 Nov 2010, Tobias Schlitt wrote: > I have studied the guidelines for releases in the ASF and tried to make > up a release process document for us. Please find it attached for > discussion. You can also find it in our SVN under > > docs/release_process.txt
My comments: > Component releases > ================== > > A component is typically maintained by a single person or a small group of > people (for simplicity, the term *maintainers* is used in following). The > maintainers of a component are in charge of proposing when a release should be > done. If the maintainers of a component decide that a release should happen, > they must choose a release manager. This choice can happen informally among > the > maintainers of a component. > > The release manager must tag the release in SVN, prepare a release package > from > this and upload it to his user space on `people.apache.org`__. He must then > call for votes on the developer mailinglist, requesting the package to be > tested by other developers. The vote must last **at least 7 days**. Every > testing developer is requested to run at least the test suite of the component > on his local system. If errors or failures occur, he is requested to vote > **-1** on the release. > > __ http://people.apache.org/ > > .. note:: Incubating phase > > After a successful vote on the developer mailinglist, the release manager > must open another vote on the Incubator PMC mailinglist for the release. > This vote must contain: > > - A reference to the RC package > - A reference to the successful developer vote > - A reference to the SVN tag for the release > > When the vote is accepted, the release manager is in charge of uploading the > release to the Apache dist server and to announce the release. > > Component releases must follow the following scheme, while each release > requires the process specified above: > > - An *alpha* release is to be held whenever a new feature has been implemented > for a component. If there are no critical issues reported within 1 week > after > officially releasing the package, the component can proceed with a *beta* > release. Otherwise, the occurred issues must be fixed before a new *alpha* > release can be rolled. > - A *beta* release is required after *alpha* stage has been completed > successfully or if the release only contains bug fixes, but no new features. > If critical issues occur 1 week after the release has been rolled, these > must > be fixed and a subsequent *beta* release must be rolled. I would also stick to what we already had here: http://incubator.apache.org/zetacomponents/community/dev_process.html#version-states > - After a successful beta stage, a stable release of the component may be > rolled. You miss here: When a release is made, the documentation should be regenerated for "latest" (which is a list of all the latest made releases from a component). Most of that stuff is documented here: http://svn.apache.org/repos/asf/incubator/zetacomponents/docs/releasing.txt > > .. note:: Determine how PEAR channel publishing can work within ASF. Proposed > is to just maintain a static PEAR channel on the main distribution > site. > > Full package release > ==================== > > A full package release does not occur as needed, but fixed dates twice a year. > > .. note:: Determine release times. I would go with "Before Christmas" and "Before the Summer holidays". > The release manager for this release is elected on the developer list through > a > vote, right after the last release has been rolled. > The full package release > does not require *alpha* and *beta* stages, since it only contains the most > recent stable releases of all components. That's a change from what we had. I would actually go with a beta period as well, where we recheck syntax and docs, and write tutorials if that's not done. > In order to roll a release, the release manager must start casting the votes > for it in the same manor as described for `Component releases`_ 2 weeks before > the release should be published. -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
