The latest version
SpamAssassin version 3.0 delivers many new features including support for sender authentication using the Sender Policy Framework (SPF), checking for web links of known spam advertisers, a modular plugin architecture, improved SQL database support for storing user data in server installations, and improved email classification.
New Release: On 2004-10-22, SpamAssassin 3.0.1 was released. [http://spamassassin.apache.org/downloads.cgi?update=200410222000 Download now], ["changes301"] notes
Release: On 2004-09-22, SpamAssassin 3.0.0 was released: [http://issues.apache.org/eyebrowse/ReadMsg?listName=users@spamassassin.apache.org&msgNo=16202 Release Announcement], [http://issues.apache.org/eyebrowse/ReadMsg?listName=users@spamassassin.apache.org&msgNo=16203 Release Notes and Information], UpgradeTo300 notes
New versions
When is the next version of Spam{{`Assassin going to be released? Spam}}`Assassin is an Open-Source project, created by team of volunteer programmers. The exact schedule depends on a number of factors and is hard to predict. The following is the current status. If you are keen to see pre-release versions, keep in mind that WeLoveVolunteers, and there's lots of DevelopmentStuff.
Version 3.0.2: Any plans yet? [http://bugzilla.spamassassin.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&target_milestone=3.0.2&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=3.0.1+Bugs&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Bug List]
- Version 3.1.0: A little ways off, way too early to guess.
How are versions numbered?
SpamAssassin uses a version numbering scheme modelled after the one used for Linux kernels. Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards.
- The major version number, currently at zero, increments upon significant architectural changes or the achievement of important milestones in capabilities. The minor/mode version number increments as progress is made within a major version, with the added constraint that:
- all external releases have an even minor/mode version number (e.g., 3.0.0)
- all internal/development versions have an odd minor/mode version number (e.g., 3.1.0)
- The patchlevel number increments for small sets of changes, providing the most fine-grain timeline of software evolution. Patchlevels increment regularly for internal/development(odd minor level) work, but only increment for external releases when an official update to the previous release version has been tested and packaged.
When a version is almost ready to be released, it is called a "release candidate," (RC), so the version will be numbered something like, "3.0.0RC3." Generally a final version is released within a few weeks of the RC versions.
Keywords: Latest Version Upgrade New Version New Release New Features