Joe Schaefer wrote:
----- Original Message ----
From: Issac Goldstand <mmsucces...@gmail.com>
To: APREQ List <apreq-dev@httpd.apache.org>
Sent: Tuesday, November 11, 2008 4:16:06 AM
Subject: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and
trunk
After reviewing the RELEASE files for 1.x and 2.x, I'd like to propose
that we clean them up a bit (though I don't forsee any more 1.3
releases, we may as well get it in at the same time as 2.x)
I won't summarize the current orders of operation (see [1] and [2]), but
here's what I'd like to see happen:
1) Create a release branch 1.x/2.x in /branches/
2) In trunk, modify the CHANGES and STATUS files to reflect a new dev cycle
3) From the branch, prep the release for CPAN (don't forget to #undef
the APREQ_VERSION_IS_DEV macro definition). Test. Upload. Vote.
Repeat if needed.
4) AFTER the release is approved by the PMC, modify the RELEASE and
STATUS files on branch + commit. Modify in trunk + commit.
The way it should work IMO is to do whatever needs doing on the branch,
including filling in the dates (a few days in advance) on the RELEASE
and STATUS files, and then generate the tarball + sig and put that
pair up for vote. If the vote doesn't pass by the dates you used,
the vote fails and that version is an unreleased dud.
That sounds right and more in line with the normal httpd release
procedure - that would mean doing (4) before (1) and leaving the rest
as-is.
