That's a big leap. It likely would be a third release item: sa, sa-ules, sa-rules-update
But it's dependent on sa libraries to work so splitting it seems a pretty big lift. Right now, I've spent a lot of time streamlining the release procedure and thanks to the new infrastructure with Dave and the sysadmins group, Release Managers can safely step up and roll a release much more easily. On 9/4/2018 2:36 PM, Michael Peddemors wrote: > Is it conceivable that sa-update might be separated from the main spam > assassin repo in the future, and be part of a sa-rules package? > > It might require the comparison of the SA Update version in place, and > the spamassassin main packages installed? > > That way changes to the way updates are handled/retrieved would not > need to rely on a complete SA release.. > > On 18-09-04 11:23 AM, Kevin A. McGrail wrote: >> Yeah, that's my thought though there is a sub for that. >> >> I think this change makes sense: >> >> Index: sa-update.raw >> =================================================================== >> --- sa-update.raw (revision 1840051) >> +++ sa-update.raw (working copy) >> @@ -26,7 +26,7 @@ >> # Subversion keyword "$Id$" has been successfully expanded. >> # Doesn't happen with automated launchpad builds: >> # https://bugs.launchpad.net/launchpad/+bug/780916 >> - $VERSION = 'svn' . (split(/\s+/, '$Id$'))[2]; >> + $VERSION = &Mail::SpamAssassin::Version . ' / svn' . (split(/\s+/, >> '$Id$'))[2]; >> } >> my $PREFIX = '@@PREFIX@@'; # substituted at >> 'make' >> time >> >> >> On 9/4/2018 1:27 PM, Michael Peddemors wrote: >>> On 18-09-04 10:21 AM, bugzilla-dae...@bugzilla.spamassassin.org wrote: >>>> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7006 >>>> >>>> --- Comment #2 from Kevin A. McGrail <kmcgr...@apache.org> --- >>>> It is updated during the build process but why are we using an svn >>>> version at >>>> all for sa-update? >>>> >>>> 3.4.1: >>>> sa-update version svn1652181 >>>> running on Perl version 5.16.3 >>>> >>>> 3.4.2 pre 5: >>>> sa-update version svn1838992 >>>> running on Perl version 5.16.3 >>>> >>>> Do we want this to be a blocker for 3.4.2, kick to 3.4.3 or mark >>>> resolved, >>>> won't fix and that it's working as intended? >>>> >>> >>> On the updated sa-update working on release for.. went with.. >>> >>> >>> sub print_version { >>> print "sa-update version $VERSION\n" >>> . " Installed SpamAssassin version $SAVersion\n" >>> . " Running on Perl version " . join(".", map { $_||=0; $_*1 } >>> ($] =~ /(\d)\.(\d{3})(\d{3})?/ )) . "\n"; >>> } >>> >>> $SAVersion is gathered via.. >>> >>> >>> my $SAVersion = get_installed_SA_version(); >>> my $RevSAVersion = join(".", reverse split(/\./, $SAVersion)); >>> >>> sub get_installed_SA_version { >>> # Figure out what version of SpamAssassin we're using, and also >>> figure out the >>> # reverse of it for the DNS query. Handle x.yyyzzz as well as >>> x.yz. >>> my $SAVersionStr = $Mail::SpamAssassin::VERSION; >>> if ($SAVersionStr =~ /^(\d+)\.(\d{3})(\d{3})$/) { >>> $SAVersionStr = join(".", $1+0, $2+0, $3+0); >>> } elsif ($SAVersionStr =~ /^(\d)\.(\d)(\d)$/) { >>> $SAVersionStr = "$1.$2.$3"; >>> } else { >>> die "fatal: SpamAssassin version number '$SAVersionStr' is in >>> an unknown format!\n"; >>> } >>> return $SAVersionStr; >>> }; >>> >>> I know.. a little 'hokey' but trying to conform to legacy methods.. >>> Was just readying an email on the subject of versions.. >>> >>> SA-Update should be independent of the installed SA, but does need to >>> check what version for some actions.. >>> >>> Per offline and online discussions, this will help facilitate rules >>> being separate from actual SA code base in the future, but trying to >>> take baby steps.. >>> >>> >>> >>> >>> >> > > > -- Kevin A. McGrail VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
