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 Schlitthttp://schlitt.infoGPG 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 t...@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
