Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk

Joe Schaefer wrote:
> ----- Original Message ----
>
>   
>> From: Issac Goldstand <[email protected]>
>> To: APREQ List <[email protected]>
>> 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.