Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
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 (pgollu...@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
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
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
- 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.
[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. 5) Tag release from branch (svn mv .../branches/xxx .../tags/xxx) 6) Upload (release) Let me know what you think: [ ] Leave everything alone [ ] Change 1.x RELEASE file [ ] Change 2.x RELEASE file (if you agree to changing both, please +1 both of the bottom two options) Issac [1] http://svn.apache.org/repos/asf/httpd/apreq/trunk/build/RELEASE [2] http://svn.apache.org/repos/asf/httpd/apreq/branches/1.x/RELEASE
