1APACHE SPAMASSASSIN RELEASE PROCEDURE 2===================================== 3 4- First off, checkout the branch or trunk you wish to build. I usually do 5 this as a privileged user in a build.tmp directory. 6 7- When working with a branch, checkout both the branch and trunk, then create 8 the symlinks mentioned below in the section on svn status 9 10- As the release gets close, consider switching to R-T-C development 11 mode: https://wiki.apache.org/spamassassin/DevelopmentMode 12 13- Using DNS resolvers like 8.8.8.8 did NOT work. It causes spurious 14 failures on things like dnsbl.t. Use a real DNS server. 15 16- To build a release you need gpg, a few perl modules, re2c 17 and the signing key for the project. For CentOS 7.5, the following worked: 18 19 - yum install gpg 20 - yum install zip 21 - yum install perl* 22 - yum remove perl-homedir 23 - yum install epel-release 24 - yum update 25 - yum install perl-BerkeleyDB 26 27 - using source and CPAN as root (cpanm -S) 28 - cpanm -S Razor2::Client::Agent 29 - cpanm -S Net::Patricia 30 - cpanm -S Geo::IP 31 - cpanm -S Devel::SawAmpersand 32 - custom compiled re2c 33 - obtained latest release tarball from github as linked from https://re2c.org as epel rpm is very old 34 - yum install gcc-c++ 35 - build with ./configure --prefix=/usr/local && make && sudo make install 36 37 For Ubuntu 20.04 minimal install, installing the following packages worked 38 39 build-essentials 40 pyzor 41 razor 42 subversion 43 libarchive-zip-perl 44 libberkeleydb-perl 45 libbsd-resource-perl 46 libdbi-perl 47 libencode-detect-perl 48 libgeo-ip-perl 49 libgeoip2-perl 50 libio-socket-inet6-perl 51 libio-string-perl 52 libmail-dkim-perl 53 libmail-spf-perl 54 libnet-patricia-perl 55 libnet-dns-perl 56 libnetaddr-ip-perl 57 libsocket6-perl 58 libsys-hostname-long-perl 59 libtest-pod-coverage-perl 60 libtest-pod-perl 61 62 - when you run perl Makefile.PL, you want full dependencies such as this 63 snippet: 64 65 checking module dependencies and their versions... 66 checking binary dependencies and their versions... 67 <snip> 68 dependency check complete... 69 70 optional binary missing or nonfunctional: fetch 71 72 - NOTE: Missing Fetch is ok if we have wget or curl. You just need 1 of 73 the 3. 74 75 - You need ~/sabuildtools/bin directory with a symlink to gpg 76 77 - You need ~/sabuildtools/sasigningkey as a gpg home directory with chmod 700, 78 e.g., a symlink to ~/.gnupg if the signing key were in your gpg keyring 79 80 - You need the passphrase to the sasigning key 81 82- Ensure ExtUtils::MakeMaker is version 6.46 or later, to create 83 a detailed-enough META.yml 84 85 perl -MExtUtils::MakeMaker -e 'print $ExtUtils::MakeMaker::VERSION' 86 87- Run "svn status" to ensure you're building/releasing from a pristine 88 checkout: 89 90 cd [checkedoutdir] 91 svn status 92 93 The output should be blank or look like this: 94 95 ? rules 96 ? rulesrc 97 ? t.rules 98 99 (ie., no "M" or "C" files; any files marked "M" have been locally 100 modified, and should be "svn revert"ed before you continue.) 101 102- Rule Source is only in trunk. If you are building a branch, checkout 103 trunk as well and symlink it, i.e. rulesrc -> ../trunk/rulesrc/ 104 105- t.rule Source is only in trunk. If you are building a branch, checkout 106 trunk as well and symlink it, i.e. t.rules -> ../trunk/t.rules/ 107 108- Rules are ONLY published from trunk. Rule development should use plugin 109 and version conditions to make it so one ruleset works on all modern 110 versions of SA. If you are building a branch, checkout trunk as well and 111 symlink the rules from trunk, i.e. rules -> ../trunk/rules/ 112 113 With the rules in trunk symlinked, you can expect MANIFEST warnings when 114 running things such as make distclean such as: 115 116 No such file: rules/20_aux_tlds.cf 117 No such file: rules/active.list 118 No such file: rules/init.pre 119 No such file: rules/languages 120 No such file: rules/local.cf 121 No such file: rules/regression_tests.cf 122 No such file: rules/sa-update-pubkey.txt 123 No such file: rules/user_prefs.template 124 No such file: rules/v310.pre 125 No such file: rules/v312.pre 126 No such file: rules/v320.pre 127 No such file: rules/v330.pre 128 No such file: rules/v340.pre 129 No such file: rules/v341.pre 130 No such file: rules/v342.pre 131 132 NOTE: Don't remove the lines from the MANIFEST though! 133 134- Consider updating the TLD list in 20_aux_tlds.cf. As of 4/6/2015, 135 this is not automated but bug 7165 is open for this purpose. 136 137- edit lib/Mail/SpamAssassin.pm and comment out the $IS_DEVEL_BUILD 138 line as noted. Ensure the correct version number is present in $VERSION 139 and @EXTRA_VERSION. 140 141 Prereleases: formatted like this: "pre4" -- in $EXTRA_VERSION, and 142 $IS_DEVEL_BUILD is 0. When referred to in full, it's "3.1.0-pre4". 143 144 Release candidates: formatted like this: "rc2" -- in $EXTRA_VERSION, and 145 $IS_DEVEL_BUILD is 0. When referred to in full, it's "3.1.0-rc2". 146 147 $IS_DEVEL_BUILD is 0 even with rc and pre versions because rc and pre 148 numbers are never reused. Just increment higher each time. 149 150 Full releases: @EXTRA_VERSION is blank and IS_DEVEL_BUILD is 0. 151 152- Ensure the new version number takes hold: 153 154 make clean ; perl Makefile.PL < /dev/null ; make 155 ./spamassassin -L -t < sample-nonspam.txt | grep X-Spam- 156 157 Verify that the X-Spam-* headers use the correct version string, 158 without an SVN revision number (those are only for dev and pre builds). 159 160 NOTE: If the date is old, don't worry, it will change later with the 161 relbuild checkout. 162 163 Also, a warning about "warn: config: could not find site rules 164 directory" is ok too. It's because no init.pre exists in the default 165 rules location. 166 167- create the Changes file. 168 169 NOTE: If you do not use a fresh checkout, you may miss recent entries if 170 you also did development on the same checkout. Use a fresh checkout 171 when making your builds to avoid this issue. 172 173 NOTE: The very old version of SVN that is included with CentOS 7 174 produces a different format of log than current versions of SVN. 175 There is no reason to create the Changes file on a CentOS 7 machine 176 rather than do the following steps with a newer version of SVN and 177 commit the Changes file, then check it out on the build machine. 178 179 MAKE CERTAIN THIS IS RUN IN THE ROOT OF YOUR CHECKOUT! 180 181 There are two options here: 182 183 - For releases on a maintenance branch (e.g. 3.0.1, .2, etc.): 184 185 TZ=UTC svn log --non-interactive --stop-on-copy > Changes 186 187 This will output all of the changes since the .0 release in the 188 current branch (the last copy -- note, if a copy was done 189 afterwards (move between repositories, etc, you'll need to 190 modify that command). 191 192 - For releases on the trunk (e.g. a .0 release): 193 194 TZ=UTC svn log -r HEAD:1567124 --non-interactive > Changes 195 196 r497472 was the release of 3.2.0-pre1; r233108 was the start of 3.2.0, 197 just after the 3.1.0 branch was created; r46030 was the start of the 198 3.1.0 work (created 3.0 branch); replace with the correct rev number 199 for the point you want to start at if different. I used r1149751 to 200 produce the first 3.4.0-pre release, for example. r1567124 is the 201 3.4.0 release tag revision. r1676613 is the 3.4.1 release tag 202 revision. 203 204 To find the release tag revision, use the tags website, i.e.: 205 https://svn.apache.org/repos/asf/spamassassin/tags/ 206 207 NOTE: 3.4.1 is currently on trunk and will be branched to 3.4 because 208 3.4 branch was not used. 209 210- Exclude some automated changes from the logs: 211 212 cat Changes | perl -ne ' BEGIN{$/=("-"x72)."\n"} 213 chomp; @ln=split/^/; 214 next if @ln==3 && $ln[2]=~/^\s*(updated scores for revision.*|promotions validated|auto-generated rules|)\s*$/; 215 print "@ln$/"' > Changes.tmp 216 217- Word wrap the Changes file with something like 218 219 fold -sw 74 Changes.tmp > Changes && rm -f Changes.tmp 220 221- run "make distcheck" to ensure all files are included in the 222 distribution that should be, and to ensure all files that are listed 223 in the MANIFEST also exist in SVN. 224 225 make distcheck 226 227 With the rules in trunk symlinked, you can expect MANIFEST warnings when 228 running things such as make distclean such as: 229make 230 No such file: rules/20_aux_tlds.cf 231 No such file: rules/active.list 232 No such file: rules/init.pre 233 No such file: rules/languages 234 No such file: rules/local.cf 235 No such file: rules/regression_tests.cf 236 No such file: rules/sa-update-pubkey.txt 237 No such file: rules/user_prefs.template 238 No such file: rules/v310.pre 239 No such file: rules/v312.pre 240 No such file: rules/v320.pre 241 No such file: rules/v330.pre 242 No such file: rules/v340.pre 243 No such file: rules/v341.pre 244 No such file: rules/v342.pre 245 246 NOTE: Don't remove the lines from the MANIFEST though! 247 248- run "make disttest" to ensure all default tests pass once the 249 distribution is fully packaged. (this takes ~12 1/2 minutes on my system 250 2018-09-01) 251 252 make disttest < /dev/null 253 254- run the release test suite, which forces all tests to run and also 255 applies an additional, more stringent set of tests. This may require 256 "sudo" privileges on your test box, and unusual CPAN modules like 257 "Devel::SawAmpersand", so you might have to skip some of this or ignore 258 some spurious failures. For example, I don't have re2c or dcc installed 259 on my devel system so I fail xt/50_dcc & xt/50_sa_compile. 260 261 262 Additionally, this will run tests such as the spamd prefork which will 263 kill all running spamd processes. This release test suite is intended 264 for a development environment. 265 266 NOTE: These likely must run as root. Some tests prompt for sudo. 267 268 make test TEST_FILES="xt/*.t" 269 270 FAILURE NOTES: 271 272 50_razor2.t - you need to register for razor 273 and the sample of a bad email may have fallen 274 out of their database. 275 276 A failure on the xt/ tests does not necessarily block a release. 277 The xt tests are intended for people rolling an SA release or custom 278 package. Expect the DCC tests to fail if DCC is not installed, etc. 279 280 281- Check in the updated Changes file, and SpamAssassin.pm. 282 283 svn commit -m "preparing to release X.Y.Z" 284 285 (If you are privately preparing a security release, and don't wish to 286 perform commits to public SVN repos, you can defer this step until 287 later.) 288 289- SVN tag the release files. This is done using "svn copy". 290 291 - For a maintenance release (x.y.1, x.y.2): 292 293 vers=3_4_3 294 295 Then run: 296 297 repo=https://svn.apache.org/repos/asf/spamassassin 298 svn delete -m "replaced old tag" $repo/tags/spamassassin_release_$vers 299 svn copy -m "creating tag for release $vers" $repo/branches/3.4 $repo/tags/spamassassin_release_$vers 300 301 302 - For a maintenance release candidate(x.y.1-rc1), pre-release (x.y.1-preZ) or alpha (x.y.1-alphaZ): 303 304 vers=3_4_3_rc_1 305 306 #Then run: 307 308 repo=https://svn.apache.org/repos/asf/spamassassin 309 svn delete -m "replaced old tag" $repo/tags/spamassassin_release_$vers 310 svn copy -m "creating tag for release $vers" $repo/branches/3.4 $repo/tags/spamassassin_release_$vers 311 312 313 - For a trunk release (x.y.0): 314 315 vers=3_4_0 316 317 repo=https://svn.apache.org/repos/asf/spamassassin 318 svn delete -m "replaced old tag" $repo/tags/spamassassin_release_$vers 319 svn copy -m "creating tag for release $vers" \ 320 $repo/trunk $repo/tags/spamassassin_release_$vers 321 322 - For a trunk release candidate (x.y.0-rc1), pre-release (x.y.0-preZ) or alpha (x.y.0-alphaZ): 323 324 vers=3_4_0_rc_2 325 326 Then run: 327 328 repo=https://svn.apache.org/repos/asf/spamassassin 329 svn delete -m "replaced old tag" $repo/tags/spamassassin_release_$vers 330 svn copy -m "creating tag for release $vers" $repo/trunk $repo/tags/spamassassin_release_$vers 331 332 333 This will do a completely server-side tagging (which is the same as 334 a branch really) of whatever the latest branch revision to be the new 335 base of the tag release. 336 337 (If you are privately preparing a security release, and don't wish to 338 perform commits to public SVN repos, you can defer this step until 339 later.) 340 341 342- Check out the code from the tag you just made: 343 344 #Switch to a non-privileged user 345 vers=3_4_3 346 repo=https://svn.apache.org/repos/asf/spamassassin 347 rm -rf ~/relbuild 348 svn co $repo/tags/spamassassin_release_$vers ~/relbuild 349 cd ~/relbuild 350 351 (If you are privately preparing a security release, you will need 352 to ensure that the code in this build directory matches up using 353 some other mechanism, since SVN is public.) 354 355- run "./build/update_stable" to build the tar.gz, tar.bz2 and zip files. 356 357 NOTE: link rules, t.rules and rulesrc to a trunk checkout if needed! 358 359 killall gpg-agent 360 #THESE ARE NOT NEEDED FOR A TRUNK RELEASE 361 ln -s ~/usr/src/Mail-SpamAssassin/trunk/rules 362 ln -s ~/usr/src/Mail-SpamAssassin/trunk/rulesrc 363 ln -s ~/usr/src/Mail-SpamAssassin/trunk/t.rules 364 ./build/update_stable 365 366 NOTE: running gpg-agent with the proper homedir is needed for 367 non-privileged users. 368 369 The above places files in ~/public_html/devel/ 370 371# This step is part of the step above already 372# 373#- run "./build/repackage_latest_update_rules" package a rule file for 374# people who can't run sa-update: 375# 376# ./build/repackage_latest_update_rules 377# 378# WARNING: this will use the most recently-created "sa-update" tarball for 379# the rules tgz, so if changes have been committed to the "rules" dir in 380# SVN since then, they will not be released! 381# 382 383- test the files! redo until they work!! ;) 384 385- Write the release announcement mail! This is a simple matter of copying 386 the previous release's announcement, updating the version numbers and 387 links, fixing the MD5 and SHA1 checksums in this mail, and summarising 388 the important changes from the Changes file. 389 390 cp build/announcements/3.4.1.txt build/announcements/3.4.2.txt 391 svn add !$ 392 vi !$ 393 394 NOTE: Here's a quick example to concat the checksums: 395 ls *3.4.2* | grep sha | xargs cat -- 396 397- If there are any issues to note, make sure to edit the UPGRADE file. 398 Every x.x.0 release at a minimum should include a section. 399 400- Check the README file for any items to change. 401 402- Review the CREDITS to update Committers - http://whimsy.apache.org/ 403 can help with this. 404 405- Review the CREDITS to update Copyright 406 407- Review the Project Branding Report Checklist at 408 https://www.apache.org/foundation/marks/pmcs 409 410- (for any rc, prerelease, or full release) Place the tarballs in a 411 discreet location (discreet means not linked from the "downloads" page 412 of the website, but included in the vote mail) and request a vote on the 413 development mailing list to make the release. Post the URL, 414 SHA sums, and proposed release announcement mail to the dev list. 415 416 http://people.apache.org/~kmcgrail/devel/ qualifies as "discreet". 417 418 Pre-releases and RCs require just lazy consensus -- ie. no objections. 419 420 NOTE: It's also feasible that you could publish via SVNPubSub as noted 421 below but using the SVN repository at: 422 423 https://dist.apache.org/repos/dist/dev/SpamAssassin 424 425- (for a pre or rc release), - upload .tar.gz (not .bz2) tarball to CPAN 426 at http://pause.cpan.org/: 427 428 https://pause.perl.org/pause/authenquery?ACTION=add_uri 429 430 See notes below for issues on indexing but the tar should be named in a 431 manner that CPAN will process it as a Developer Release per 432 433 http://www.cpan.org/modules/04pause.html#developerreleases 434 435 As of 2014-02-05, adding -TRIAL to the filename should work. For example: 436 437 Mail-SpamAssassin-3.4.1-rc2-TRIAL.tar.gz 438 439- (for a full release) 3 +1's votes from PMC members are required to 440 proceed with an official, non pre-release ASF software release. 441 442- If you've been doing some steps in private, for a security release, 443 now's the time to perform them publicly; tagging etc. 444 445- Edit lib/Mail/SpamAssassin.pm, and uncomment the $IS_DEVEL_BUILD line. 446 SVN commit it (and the release announcement file from above, if 447 you made one): 448 449 svn commit -m "X.Y.Z RELEASED" 450 451- [X.Y.0 RELEASES ONLY]: Now, start the new development codebase. For 452 minor updates of a 2.x tree (e.g. 2.x.1, 2.x.2), you don't need to 453 branch; for major updates (2.x.0) you need to create a new development 454 branch, off the trunk. 455 456 repo=https://svn.apache.org/repos/asf/spamassassin 457 svn copy $repo/tags/spamassassin_release_3_4_1 $repo/branches/3.4 \ 458 -m 'Creating 3.4 branch based on 3.4.1 so that trunk can go to 4.0' 459 460 "trunk" is SVN's concept of head. Typically, our branches are named 461 for their minor version number. In the example above, 3.4 is the 462 branch for the stable 3.4.x releases. 463 464 - In the new development codebase, edit lib/Mail/SpamAssassin.pm 465 and bump the $VERSION line to the correct version. 466 467 - then, commit the new version number to the new branch: 468 469 svn commit -m "X.Y.N devel cycle started" 470 471 (where X.Y.N is the new version number) 472 473- [X.Y.0 RELEASES ONLY]: in trunk, bump the version to the correct 474 version in the following files (just as above for the branch): 475 476 - lib/Mail/SpamAssassin.pm 477 478 479#- In build/mkupdates/run_part2 change versions="X.Y.Z" to the new 480# development version (A.B.C). 481 482- DNS Steps TBD - Talk to sysadmins@spamassassin.apache.org 483 484#- [X.Y.0 RELEASES ONLY]: NOTE: This may change, make sure this info is 485# still accurate before changing this (preferrably find out BEFORE doing 486# an X.Y.0 release. Update the mkupdates stuff: 487 488# - Create an empty file for the new version number in 489# /var/named/updates.dev.spamassassin.org.d/ on the zone and chown to 490# updatesd and chgrp to others. 491# 492# NOTE: I don't believe this does anything KAM: 2014-02-11 and the 493# directory doesn't exist. 494 495# - Add "$INCLUDE /var/named/updates.spamassassin.org.d/X.Y+1.0" to the 496# /var/named/spamassassin.org zone file OR use a CNAME (see below) 497# 498# NOTE: Per bug 6644, using a CNAME for 3.4.1, 3.4.2, 4.0.0 to 3.3.2 499 500# - commit the changes, update the zone (if not doing above on the zone - 501# NOTE: See /var/named/README) and tick the zone file using build/mkupdates/tick_zone_serial 502 503- !WARNING! After the next step, the version number will be considered 504 "burned". The number is locked for this particular code. The same 505 number cannot be used for a future different release. So make sure 506 you're happy before you go on! 507 508 If you need to redo something, re-comment the $IS_DEVEL_BUILD line, 509 revert the $VERSION bump, and go back to 'Ensure the new version number 510 takes hold'. You can retag with the normal 'svn copy' command used in 511 'SVN tag the release files', even if that tag already existed; but be 512 sure to check in another commit message to note what happened, e.g.: 513 514 svn commit -m "oops, had to redo: THIS IS THE REAL X.Y.Z RELEASE" 515 516#- Release a new rules update matching the released code: 517# #2014-02-11 switched to su - instead of sudo because of .ssh and .svn 518# stored config items 519# 520# ssh spamassassin.zones.apache.org 521# su - updatesd 522# cd /home/updatesd/svn/spamassassin/build/mkupdates 523# ./update-rules-3.3 3.4 524# 525# NOTE: Is this needed with our rule update process? not convinced it 526# is... 2015-04-28 527 528- publish the tarballs 529 530 ASF bylaws prohibit the distribution of files claiming to be 531 releases from the website, without 3 PMC +1 votes, so you need to 532 make it clear that this is an unofficial "test build" by placing it 533 in your public_html dir: 534 535 http://people.apache.org/~kmcgrail/devel/ for example 536 537 NOTE: It's also feasible that you could publish via SVNPubSub as noted 538 below but using the SVN repository at: 539 540 https://dist.apache.org/repos/dist/dev/SpamAssassin 541 542 The choice is up to the Release Manager for these test builds. 543 544 545 For full release builds, you need to publish using SVNPubSub. 546 547 This is a simple matter of committing the new artifacts and signature 548 files to https://dist.apache.org/repos/dist/release/spamassassin/ once a 549 release vote passes. 550 551 NOTE - Since it takes up to 24 hours for all the mirrors of dist.apache.org 552 to receive changes, for a full release upload the files immediately 553 when the 72 hour period for a successful PMC vote has completed, then 554 you can start preparing the various news and announcements that you can't 555 commit or send until 24 hours after the upload. 556 557 [note: Symlinks may not work on all mirrors even though there may be 558 documentation to the contrary.] 559 560 As documented at http://www.apache.org/dev/release.html, SpamAssassin 561 as of 2014-02-26 publishes tarballs by manipulating the repo on svn. 562 563 svn co https://dist.apache.org/repos/dist/release/spamassassin/ release 564 565 - Manipulate the files to add the new version artifacts to the source dir 566 - Remove tar-balls for now-obsolete versions from dist: 567 568 Only the most recent version of each supported release line should be 569 stored. The archives will auto update. 570 See http://www.apache.org/dev/release#archived. 571 - Commit 572 - Wait 24 hours before you announce to allow mirrors to update 573 574 (NOTE: it may be better to wait a while before doing this; it appears to 575 take a while for the spamassassin.apache.org website mirror script to 576 run, so the old downloads page will stick around for a while before it's 577 safe to do so.) 578 579- (for full release builds) Update the files in build/announcements/$vers.txt 580 to insert the correct checksums for the files that were uploaded. This directory 581 is not part of the release tarball, so committing it does not change the hashes. 582 583- (for full release builds) update the main website "downloads.html" to link to 584 the new version of download files. This will involve changing the version number 585 in the download links for the install files, their detached GPG signature and hashes, 586 and the link to the announcement text. 587 588 https://svn.apache.org/repos/asf/spamassassin/site 589 590 Previous versions of this README talked about using a timestamp in the 591 downloads.cgi links. However the instructions in 592 https://infra.apache.org/release-download-pages.html#less-than-24hr 593 say not to do that as a main website link. There is no need for a timestamp 594 once the mirrors have all updated. Also, if the old version that is obsoleted 595 by the new release is deleted as we are instructed to do, then not having 596 updated the website download pages will result in 404 links for all the 597 mirror sites that have already syncronized. It is probably fine to just wait 598 a few hours for a number of sites to sync, and then just accept the possibility 599 that there may be some people who try to download the new release and get a 404 600 then try the backup mirror site which will probably be the main one which 601 will work. 602 603- Update the "news.html" and the announcement on the home page. 604 605- Log on to: https://reporter.apache.org/addrelease.html?spamassassin 606 and add your release data (version and date) to the database. 607 608- update the 'doc' tree in the SpamAssassin website 609 610 WARNING: edit 'build/update_website_docs' beforehand and set the "PERL" 611 "WEBDIR" and "vers" lines. On my build system, the website checkout is 612 in ~/asf/Mail-SpamAssassin/site and perl is in the path so nothing special is 613 needed. 614 615 #If needed, remove the old docs - This will be different for v4.0 616 cd ~/asf/Mail-SpamAssassin/site 617 svn up 618 svn delete --force full/3.4.x 619 svn commit -m "removing old doc tree from website" 620 621 #Checkout the current release 622 cd /tmp 623 svn checkout https://svn.apache.org/repos/asf/spamassassin/tags/spamassassin_release_3_4_3/ release 624 cd /tmp/release 625 #link your rules and rulesrc 626 ln -s ~/usr/src/Mail-SpamAssassin/trunk/rules 627 ln -s ~/usr/src/Mail-SpamAssassin/trunk/rulesrc 628 build/update_website_docs 629 630 cd ~/asf/Mail-SpamAssassin/site 631 svn add full/3.4.x 632 svn commit -m "updating new doc tree on website" full 633 634- update the tag used to point to "current release": 635 636 repo=https://svn.apache.org/repos/asf/spamassassin 637 vers=3_4_3 638 svn delete -m "updating for new release" $repo/tags/spamassassin_current_release_3.4.x 639 svn copy -m "updating for new release" $repo/tags/spamassassin_release_$vers $repo/tags/spamassassin_current_release_3.4.x 640 641- upload release .tar.gz (not .bz2) tarball to CPAN at http://pause.cpan.org/: 642 643 https://pause.perl.org/pause/authenquery?ACTION=add_uri 644 645 (Note that recently, PAUSE has started indexing sub-modules under 646 Mail::SpamAssassin::, and it can't deal with our multi-maintainer 647 setup. You may receive mail indicating that "indexing failed" after 648 the upload; as long as the main Mail::SpamAssassin module was indexed 649 correctly, this is fine. However, it would help if you could visit 650 651 https://pause.perl.org/pause/authenquery?ACTION=share_perms 652 653 select 3.1 ("Make someone else co-maintainer"), and ensure that the 654 other releasers (JMASON, DOS, FELICITY, others?) all have permissions as 655 'co-maintainer' on the full set of your listed modules in the 656 "Mail::SpamAssassin::" namespace. 657 658- announce on the users@spamassassin.apache.org, 659 dev@spamassassin.apache.org, announce@spamassassin.apache.org and the 660 announce@apache.org mailing lists using the previously-prepared release 661 announcement. 662 663 **IMPORTANT: Address the email to yourself as the To:, Bcc: all lists 664 and set a Reply-To: of dev@spamassassin.apache.org. 665 666 NOTE: you must send this mail with a "From:" address @apache.org, 667 otherwise it'll be bounced by the ASF's custom spam filtering 668 rules. See [1] below for more requirements for the announce email. 669 670- Approve the posting to the announce list (the list admins will get a 671 mail indicating how to do this.) 672 673- Add the new version to the Bugzilla versions list: 674 675 http://issues.apache.org/SpamAssassin/editversions.cgi?product=Spamassassin&action=add 676 677- Add a milestone for the next version to the Bugzilla milestones list: 678 679 https://issues.apache.org/SpamAssassin/editmilestones.cgi?action=add&product=Spamassassin 680 (use a sortkey of "0") 681 682- Confirm with SpamAssassin SysAdmins group that we are ready in DNS for 683 masscheck and rule updates for the next version 684 685 For many years all releases since 3.3.3 use the same ruleset. 686 3.4.2 already has a cname for this. 687 3.3.2 and before are set to a static ruleset. 688 689 We have been good on using version specific and plugin conditions to 690 allow one ruleset to rule them all. 691 692 Since we plan to release rules that continue to be version compatible 693 back to 3.3.3, only a CNAME is needed for newer releases to point at 694 3.3.3. 695 696- Change the sortkey for the previous release's milestone from "0" to "10": 697 698 https://issues.apache.org/SpamAssassin/editmilestones.cgi?product=Spamassassin 699 700- Update http://en.wikipedia.org/wiki/SpamAssassin 701 702 703 704 705------------- 706[1] 707 708Hello PMCs --a quick reminder that messages sent to announce@apache.org 709feature prominently in the weekly Apache News Round-ups [1]. 710 711In order for your announcement be happily moderated through, don't forget 712to: 713 7140) write "[ANNOUNCE]", "[ANN]", or "[SECURITY]" in the subject line as 715appropriate 716 7171) send the email in PLAINTEXT --all else will be rejected 718 7192) include the appropriate URL for downloading the release or more 720information regarding the announcement 721 7223) include the DOAP! Whilst you may know what your project is, there's a 723chance that others don't, particularly those with funky names/acronyms. 724Hone your message and polish that one-liner! 725 7263a) speaking of DOAP, relationships are nice --does your project 727involve/play with other technologies? If so, state the relationship. 728 7294) include a way for folks to learn more. Link to the project home page or 730a mailing list or some other relevant resource. 731 7325) personalize your closing --whether your choose to sign off using your 733name or (on behalf of) the collective PMC, doing something friendly 734reinforces the "community" aspect of the ASF. 735 736 737Thanks so much, 738Sally 739 740 741[1] https://blogs.apache.org/foundation/date/20150612 742// vim:tw=74: 743