You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by si...@apache.org on 2024/03/29 21:40:10 UTC

svn commit: r1916640 - /spamassassin/trunk/build/README

Author: sidney
Date: Fri Mar 29 21:40:10 2024
New Revision: 1916640

URL: http://svn.apache.org/viewvc?rev=1916640&view=rev
Log:
Update build/release document to remove obsolete sections and update based on last release experience, correct typos

Modified:
    spamassassin/trunk/build/README

Modified: spamassassin/trunk/build/README
URL: http://svn.apache.org/viewvc/spamassassin/trunk/build/README?rev=1916640&r1=1916639&r2=1916640&view=diff
==============================================================================
--- spamassassin/trunk/build/README (original)
+++ spamassassin/trunk/build/README Fri Mar 29 21:40:10 2024
@@ -338,22 +338,19 @@ Run "svn status" to ensure you're buildi
 
 - (for any rc, prerelease, or full release) Place the tarballs in a
   discreet location (discreet means not linked from the "downloads" page
-  of the website, but included in the vote mail) and request a vote on the
-  development mailing list to make the release.  Post the URL,
-  SHA sums, and proposed release announcement mail to the dev list.  
+  of the website, but included in the mail to the dev list) Post the URL,
+  SHA sums, and proposed release announcement mail to the dev list.
+  If this is for a full release, make the subject of the mail
+  [VOTE] Release of X.Y.Z - vote will close on XXXday, MONTH DD, YYYY HH:MM UTC
+  and have the mail call for a 72 hour vote for release.
 
     https://people.apache.org/~kmcgrail/devel/ qualifies as "discreet".
 
   So is https://dist.apache.org/repos/dist/dev/spamassassin/
 
-  Pre-releases and RCs require just lazy consensus -- ie. no objections.
+  Pre-release and RC don't need votes if only announced to the dev list.
 
-  NOTE: It's also feasible that you could publish via SVNPubSub as noted
-  below but using the SVN repository at:
-
-    https://dist.apache.org/repos/dist/dev/SpamAssassin
-
-- (for a pre or rc release), - upload .tar.gz (not .bz2) tarball to CPAN
+  - (for a pre or rc release), - upload .tar.gz (not .bz2) tarball to CPAN
   at https://pause.cpan.org/:
 
         https://pause.perl.org/pause/authenquery?ACTION=add_uri
@@ -367,8 +364,16 @@ Run "svn status" to ensure you're buildi
 
         Mail-SpamAssassin-3.4.1-rc2-TRIAL.tar.gz
 
+- (for a full release) Send email to sysadmins@spamassassin.apache.org
+  requesting that a CNAME record be created so rule updates can work
+  with the new version number that will be created in svn after the
+  release is completed. There is no harm in this being done in advance,
+  and doing it at the start of the 72 hour vote period allows for it
+  to be done before the new version number is committed.
+  
 - (for a full release) 3 +1's votes from PMC members are required to 
-  proceed with an official, non pre-release ASF software release.
+  proceed with the next steps for an official, non pre-release ASF
+  software release.
 
 - If you've been doing some steps in private, for a security release,
   now's the time to perform them publicly; tagging etc.
@@ -406,56 +411,23 @@ Run "svn status" to ensure you're buildi
 
   - lib/Mail/SpamAssassin.pm
 
-
-#- In build/mkupdates/run_part2 change versions="X.Y.Z" to the new
-#  development version (A.B.C).
-
-- DNS Steps TBD - Talk to sysadmins@spamassassin.apache.org
-
-#- [X.Y.0 RELEASES ONLY]: NOTE: This may change, make sure this info is
-#  still accurate before changing this (preferrably find out BEFORE doing
-#  an X.Y.0 release.  Update the mkupdates stuff:
-
-#  - Create an empty file for the new version number in
-#    /var/named/updates.dev.spamassassin.org.d/ on the zone and chown to
-#    updatesd and chgrp to others.
-#
-#    NOTE: I don't believe this does anything KAM: 2014-02-11 and the
-#    directory doesn't exist.
-
-#  - Add "$INCLUDE /var/named/updates.spamassassin.org.d/X.Y+1.0" to the
-#    /var/named/spamassassin.org zone file OR use a CNAME (see below)
-#
-#    NOTE: Per bug 6644, using a CNAME for 3.4.1, 3.4.2, 4.0.0 to 3.3.2
-
-#  - commit the changes, update the zone (if not doing above on the zone -
-#    NOTE: See /var/named/README) and tick the zone file using build/mkupdates/tick_zone_serial
+- (full release only) If you didn't send that email about DNS CNAME
+  to sysadmins@spamassassin.apache.org before the vote, do it now!
 
 - !WARNING! After the next step, the version number will be considered
   "burned". The number is locked for this particular code.  The same
   number cannot be used for a future different release.  So make sure
   you're happy before you go on!
 
-  If you need to redo something, re-comment the $IS_DEVEL_BUILD line,
-  revert the $VERSION bump, and go back to 'Ensure the new version number
-  takes hold'.  You can retag with the normal 'svn copy' command used in
+  If you need to redo something, before the next step is done,
+  re-comment the $IS_DEVEL_BUILD line, revert the $VERSION bump,
+  and go back to 'Ensure the new version number takes hold'.
+  You can retag with the normal 'svn copy' command used in
   'SVN tag the release files', even if that tag already existed; but be
   sure to check in another commit message to note what happened, e.g.:
 
     svn commit -m "oops, had to redo: THIS IS THE REAL X.Y.Z RELEASE"
 
-#- Release a new rules update matching the released code:
-#  #2014-02-11 switched to su - instead of sudo because of .ssh and .svn
-#  stored config items
-#
-#        ssh spamassassin.zones.apache.org
-#        su - updatesd
-#        cd /home/updatesd/svn/spamassassin/build/mkupdates
-#        ./update-rules-3.3 3.4
-#
-#  NOTE: Is this needed with our rule update process?  not convinced it
-#  is... 2015-04-28
-
 - publish the tarballs
 
   ASF bylaws prohibit the distribution of files claiming to be
@@ -472,7 +444,6 @@ Run "svn status" to ensure you're buildi
 
   The choice is up to the Release Manager for these test builds.
 
-
   For full release builds, you need to publish using SVNPubSub.
  
   This is a simple matter of svn committing the new artifacts and signature 
@@ -483,7 +454,7 @@ Run "svn status" to ensure you're buildi
   downloads with use of a global CDN. As a result, there is no longer a
   delay after uploading files until the files are visible. If you are
   used to the old system requiring you to wait 24 hours after uploading
-  before updating the download page om the web site and annouincing the
+  before updating the download page on the web site and announcing the
   release, rejoice, you no longer need to.
   
   Publish tarballs by manipulating the repo on svn, which is at