Hi, please vote on the release process as described in the attached document, which corresponds to the most recent revision in SVN.
[ ] +1 (accept release process) [ ] 0 (I don't care) [ ] -1 (decline release process, because …) Voting will last 72 hours (Thursday this week). Cheers, Toby -- Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14 Want to hire me? Need quality assurance? http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
=============== Release process =============== :author: Tobias Schlitt <[email protected]> :status: Draft This document defines the release process for the Apache Zeta Components project. The release process complies to the Apache Software Foundation release guidelines. ----------------- Guideline summary ----------------- The ASF release guidelines can be found online in for of a `release FAQ`__. There is also a non-nomerative draft of a `guide to release management`__, which gives practical help on how releases could be managed. This section summarizes the most important points from both documents, which affect changes in the release process originally defined by the eZ Components project. __ http://www.apache.org/dev/release.html __ http://incubator.apache.org/guides/releasemanagement.html Definition of a release ======================= In eZ Components, a release was defined as a stable version of a component or the full components package. The ASF defines releases somewhat differently as **every publically announced download package**. In short there exist two fundamentally different kinds of download packages: - Test packages - Nightly builds - Release candidates (RCs) - Releases - Everything else It is important to note, that RC is defined differently, compared to eZ Components terminology. In eZ Components, the RC was a non-stable package immediatelly preceeding a stable release (alpha â beta â RC â stable). In ASF, an **RC is any kind of package that is meant to be published later**, but is at first only provided to developers for testing. In summary: A release is every distribution made available to people outside the developer mailinglist. An RC is a release package which has not been announced publically, yet, but has only been made available to the developer list for testing purposes. Approval process ================ In the eZ Components project, the core development team (consisting of developers employed by eZ Systems) was responsible for approving and rolling releases. In the ASF, the whole developer community is involved in the approval of a release. Before releasing any package, the corresponding release manager is meant to cast a vote on the developer list. In order to approve a release, the desired distribution package must be made available to the developers in form of a preliminary RC package (see `Definition of a release`_). Note, that all releases must be provided with a **cryptographical signature** of the release manager in charge. This signature must be validated by testers. Optionally, testing developers should provide their signature in addition, in order to confirm the release. There is a document on `release signing`__ provided by the ASF. __ http://www.apache.org/dev/release-signing.html For incubating podlings, each release also needs to be approved by an Incubator PMC vote. Release publishing ================== Releases of ASF projects are distributed under `www.apache.org/dist/`__, not on the project website. For the Apache Zeta Components podling, the appropriate location seems to be `www.apache.org/dist/incubator/zetacomponents`__. .. note:: This directory should be verified. __ https://www.apache.org/dist/ __ https://www.apache.org/dist/incubator/zetacomponents/ --------------- Release process --------------- The Apache Zeta Components project requires two kinds of releases: - Component releases - Full package releases The first type refers to a release of a single component, independently from any other. The latter type refers to a full package release of Apache Zeta Components, containing all components. 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 cast 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 This process is dropped, once Zeta Components graduated to a top-level Apache project. 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. - After a successful beta stage, a stable release of the component may be rolled. .. 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: - Before the summer vacation time (around July) - Before X-mas (early December) A release manager for the next release is elected on the developer list through a vote, right after the last release has been rolled. He is responsible for tracking the release, casting the necessary votes and for packaging and distributing it. Announcements ============= Every publically available release must be announced through the official Apache announcement list at ``[email protected]``. Furthermore, there should a news entry be published on the website in ``news/``. It is also desirable that community members (maybe the release manager) blog about the release so the word is spread wide enough. .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79
