Bug 3566 - RFE: support "3.1.7"-style version numbering in 'require_version'
Summary: RFE: support "3.1.7"-style version numbering in 'require_version'
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P5 normal
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
Depends on:
Reported: 2004-07-03 14:49 UTC by Klaus Heinz
Modified: 2010-04-21 20:21 UTC (History)
0 users

Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Heinz 2004-07-03 14:49:05 UTC
With "require_version 3.0" in my local.cf I see this:

Jul  3 22:49:24 silence spamd[2180]: configuration file "/usr/pkg/etc/spamassass
in/local2.cf" requires version 3.0 of SpamAssassin, but this is code version 3.0
00000. Maybe you need to use the -C switch, or remove the old config files? Skip
ping this file at /usr/pkg/lib/perl5/site_perl/5.6.1/Mail/SpamAssassin/Conf/Pars
er.pm line 314.
Jul  3 22:49:35 silence spamd[2180]: server started on port 783/tcp (running ver
sion 3.0.0-pre1)

X-Spam-Checker-Version: SpamAssassin 3.0.0-pre1 (2004-06-19) on
X-Spam-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,
        FORGED_RCVD_HELO autolearn=no version=3.0.0-pre1

Obviously 3.0 != 3.000000 (and != 3.0.0-pre1).  There should be only one kind
of version number used by SA, at least where it is visible to the user or
mail administrator.

Comment 1 Theo Van Dinter 2004-07-03 15:25:27 UTC
There's the internal version (x.yyyzzz) which is used in require_version (I've
added some documentation about this in the POD) and for CPAN, etc.  Then there's
the user-visible version (x.y.z{-anything}).  They are, unfortunatly, both
required to be in different formats.

"3.0" isn't a valid version number in and of itself (does it mean "3.0.0" or
"3.0.#"?)  I was thinking about having "require_version" understand the latter
there, so "require_version 3.1" would work for all 3.1 versions, but the code
doesn't support it yet.

I'd probably end up making a function "version_gen_to_int" or something which
takes some value that should be considered a version, and convert it into the
internal x.yyyzzz number format.  ie: it's the reverse of M::SA::Version().


3.0 -> 3.000
3.0.0-pre1 -> 3.000000
randomjunk -> randomjunk  (act as a pass through)
3 -> 3.

Then instead of "required ne current" we do some form of
"substr(current,0,length required) ne required".
Comment 2 Malte S. Stretz 2004-07-05 05:20:54 UTC
Good plan. Some code which handles both the x.y.z and the x.yyyzzz variant can 
be found in the first foreach loop of spamc/version.h.pl. 
Comment 3 Daniel Quinlan 2005-03-30 01:09:11 UTC
move bug to Future milestone (previously set to Future -- I hope)
Comment 4 Justin Mason 2006-12-05 05:44:29 UTC
this'd be nice but without code it's not going to make it into 3.2.0
Comment 5 Justin Mason 2006-12-05 06:10:00 UTC
really move this time
Comment 6 Justin Mason 2009-03-31 02:47:47 UTC
lowering priority
Comment 7 Justin Mason 2010-01-27 02:20:28 UTC
moving most remaining 3.3.0 bugs to 3.3.1 milestone
Comment 8 Justin Mason 2010-01-27 03:16:17 UTC
reassigning, too
Comment 9 Justin Mason 2010-03-23 16:33:23 UTC
moving all open 3.3.1 bugs to 3.3.2
Comment 10 Karsten Bräckelmann 2010-03-23 17:42:36 UTC
Moving back off of Security, which got changed by accident during the mass Target Milestone move.