You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@yahoo.com> on 2009/01/08 06:57:02 UTC
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
----- Original Message ----
> From: Issac Goldstand <mm...@gmail.com>
> To: APREQ List <ap...@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.
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for
1.x and trunk
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Issac Goldstand wrote:
>>
> 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.
Pretty much, yup. The confusion reigns when we aren't sure if a user is
complaining about 1.34-dev, 1.34-RC1, 1.34-RC2 or 1.34-Gold. So this gives
us a very simple binary question (did you grab from SVN or take a release
al la CPAN) to decide if the user is running what we expected.
And as folks have hinted, version no's are cheap :)
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for
1.x and trunk
Posted by Issac Goldstand <ma...@beamartyr.net>.
Philip M. Gollucci wrote:
> Issac Goldstand wrote:
>> 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.
> Well, my first attempt at writing that out was close :)
>
> Issac go-ahead and make the changes to RELEASE file and re-roll
> without the polished version. I think we can stick with v1.34 for
> this one.
>
Already rolled, and at a mirror near you, as libapreq-1.34.tar.gz
I'll call the vote in a separate email
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for
1.x and trunk
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Issac Goldstand wrote:
> 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.
Well, my first attempt at writing that out was close :)
Issac go-ahead and make the changes to RELEASE file and re-roll without the
polished version. I think we can stick with v1.34 for this one.
I'll dedicate some time tonight or tomorrow to test it.
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior Sys Admin - RideCharge, Inc. http://ridecharge.com
Contractor - PositiveEnergyUSA http://positiveenergyusa.com
ASF Member - Apache Software Foundation http://apache.org
FreeBSD Committer - FreeBSD Foundation http://freebsd.org
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for
1.x and trunk
Posted by Issac Goldstand <ma...@beamartyr.net>.
Joe Schaefer wrote:
> ----- Original Message ----
>
>
>> From: Issac Goldstand <mm...@gmail.com>
>> To: APREQ List <ap...@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.