New versions
When is the next version of SpamAssassin going to be released?
...
Short answer: When it's ready.
Longer answer: Probably sooner if you help.
Because of the way SpamAssassin's default scores are determined, it generally takes a lot longer to release major versions (i.e. x.x.0 or x.x0) than we'd like. Here are the major steps we take before a release.
Wiki Markup All the bugs that we agree need to be done for the next release need to be fixed. (For 3.0.0, you can look at \[http://bugzilla.spamassassin.org/show_bug.cgi?id=3208 bug 3208\], you can also query for bugs where the target milestone is 3.0.0) 2. We need to enter a rule freeze and run 3 mass-checks (MassCheck) and perceptron runs to optimize the rule scores. Since these mass-checks require volunteers from around the world to run [SpamAssassin] over very large volumes of mail, these generally take about a week each. 3. We need roughly two weeks of testing to eradicate any major bugs that creep in. (It's difficult to test [SpamAssassin] before the mass-checks are done because the scores are generally quite poor, making it relatively unusable on real mail.) During this time we will generally distribute release-candidate (RC) releases for wider testing. Test these! 4. If all goes well, we release. \\
Minor releases tend to have a lot shorter release schedule as only important bug fixes happen and the scores (usually) stay the same.
| Wiki Markup |
|---|
How can you help? Simple. Fix bugs. Log into \[http://bugzilla.spamassassin.org Bugzilla\] and browse through the bugs that are holding up the release. Fix them and attach patches to the bugs. (If the fix isn't trivial, you may need to also fill out and send in a \[http://www.apache.org/licenses/#clas Contributor License Agreement\] before we can use your patch.) Also, [WeLoveVolunteers]. |
(DuncanFindlay)
Schedule for SpamAssassin 3.0
The following schedule was first posted by TheoVanDinter to the SpamAssassin development mailinglist on April 21st 2004. He wrote:
Here's what I came up with. These are meant to be guidelines, not
hard dates. This schedule has a release in 10 weeks. I'd really like
to beat that. Depending on schedules, we can probably move up the code
related work. The release related stuff is pretty much the amount of
time it usually takes though.
The schedule is a bit outdated and only a rough timeline
| Wiki Markup |
|---|
Open bugs blocking 3.0.0 are tracked via the meta-bug \[http://bugzilla.spamassassin.org/show_bug.cgi?id=3208 3208\], the dependency tree gives a good \[http://bugzilla.spamassassin.org/showdependencytree.cgi?id=3208 overview\]. The Fedora guys track their [SpamAssassin] 3.0 related bugs \[https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=123710 here\], an overview of Debian bugs is \[http://packages.qa.debian.org/s/spamassassin.html here\], Gentoo bugs are \[http://bugs.gentoo.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=SpamAssassin&product=Gentoo+Linux&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED here\]. |
Code Related
04/20: DONE - get bugzilla prioritized and either close/punt stuff we're not going to get to to 3.1. We will need to get agressive about some tickets – for instance: we can't avoid all FPs, so if they don't happen often and if it's not easy to fix, accept it, close the ticket, and move on. Get open 3.0 tickets down to around 50.
04/22: ACTIVE - feature freeze – no more adding enhancements to 3.0 w/out vote
04/28: DONE - do bug squashing event for as many remaining open tickets as possible. I assume there'll still be a few major ones open.
05/12: all tickets should be finished and closed. all testing rules should be promoted or removed. do testing to make sure the mass-checks will be smooth.
Release Related
05/07: warn people that mass-check runs will be starting shortly
05/17: announce mass-check run 1 (sets 0 and 1), run until 05/24. enter R-T-C mode.
05/26: generate scores, etc.
05/31: announce mass-check run 2 (sets 2 and 3), run until 06/11.
06/13: generate scores, etc.
06/15: release 3.0.0rc1 – fix bugs that come up, do polishing, etc. release other 3.0.0rc as appropriate.
The exact schedule depends on a number of factors and is hard to predict. If you are keen to see pre-release versions, keep in mind that WeLoveVolunteers, and there's lots of DevelopmentStuff.
The news page contains the list of release dates nowadays.
ReleaseGoals lists the times releases are intended to be started.
How are versions numbered?
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 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.
- 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.0-rc3." Generally a final version is released within a few weeks of the RC versions.
...
Keywords: Latest Version Upgrade New Version New Release New Features06/30: planned release of 3.0.0-final