incubator-zeta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Derick Rethans <der...@apache.org>
Subject Re: [zeta-dev] Proposal: Release process
Date Fri, 26 Nov 2010 13:34:42 GMT
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

Mime
View raw message