incubator-zeta-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From t...@apache.org
Subject [zeta-commits] svn commit: r1031059 - /incubator/zetacomponents/docs/release_process.txt
Date Thu, 04 Nov 2010 16:21:27 GMT
Author: toby
Date: Thu Nov  4 16:21:26 2010
New Revision: 1031059

URL: http://svn.apache.org/viewvc?rev=1031059&view=rev
Log:
- Added: Initial draft for a release process.

Added:
    incubator/zetacomponents/docs/release_process.txt   (with props)

Added: incubator/zetacomponents/docs/release_process.txt
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/docs/release_process.txt?rev=1031059&view=auto
==============================================================================
--- incubator/zetacomponents/docs/release_process.txt (added)
+++ incubator/zetacomponents/docs/release_process.txt Thu Nov  4 16:21:26 2010
@@ -0,0 +1,172 @@
+===============
+Release process
+===============
+
+:author:    Tobias Schlitt <toby@apache.org>
+: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 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.
+- 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.
+
+.. note:: Determine release times.
+
+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.
+
+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.
+
+
+..
+   Local Variables:
+   mode: rst
+   fill-column: 79
+   End: 
+   vim: et syn=rst tw=79

Propchange: incubator/zetacomponents/docs/release_process.txt
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message