Please use version numbers whose correct order is obvious

[smcv]

It looks as though the iortcw version numbers are intended to be treated like decimal floating-point: 1.4 < 1.41 < 1.5. However, version numbers are usually sorted as though they were vectors of integers: for example, Linux 3.2, 3.9, 3.10, 3.11 were released in that order. Package management tools like dpkg and RPM assume the vector-of-integers interpretation.

Please could you use versions like 1.50b, 1.51a or 1.60a for future releases, so that both interpretations lead to the version numbers being sorted in the same order?

(For now, I'm going to prepare Debian packages for 1.5a as though it had been versioned 1.50a.)

[MAN-AT-ARMS]

I'll consider it but don't change the version number.

[smcv]

I can't upload 1.5a without changing the version number (or adding an "epoch" prefix 1: that I then have to keep forever).

[smcv]

I'll hold off on uploading anything based on 1.5a until we've worked out something that can work.

[MAN-AT-ARMS]

Note: This is how RTCW numbering has always been.

[MAN-AT-ARMS]

Go ahead and use 1.50a. I won't be using that number going forward.

[smcv]

Thanks, proceeding with 1.50a.

I can't make an exception to how dpkg sorts versions to make it match RTCW's expectations: this is how the Debian archive works (and also how RPM, Arch, Gentoo, etc. work), and I can't change that. Every distribution that wants to package iortcw is going to have to solve this, one way or another. If you have a preference for which solution is chosen, you can nudge distributions towards it.

If I'd ever packaged a version older than 1.41, then I would have had to either represent 1.4 as 1.40 (and so on) for dpkg's purposes, or represent 1.41 as 1.4.1. Having already packaged 1.42d as 1.42d, that second option is no longer available to me, unless I add an epoch prefix so users upgrade from 1.42d to 1:1.5a, and then from 1:1.5a to, say, 1:1.5.2b (which would be your 1.52b release).

I'd prefer to avoid invoking epochs unless I really can't avoid it, because they're an ugly and technically problematic special case - they're intended as a way to escape from situations where an upstream has changed how they do versioning, or where an upstream or downstream maintainer made a mistake. dpkg (Debian/Ubuntu) and RPM (Fedora/SuSE/etc.) have epochs, but I don't think they're available in some of the more minor packaging systems, so it would be best if we could avoid relying on them.

[smcv]

If you're never going to release a version labelled 1.50a (reserving that version number for me to use to represent 1.5a), and you're going to version all releases with 2 digits in future (so the version between 1.59 and 1.61 is 1.60), then I consider this issue to have been resolved and it can be closed whenever convenient.

[MAN-AT-ARMS]

Yes. I wasn't aware of the packaging issue. I'll use two digits going forward. I have next one set to be 1.51...probably will stay on that version number for a while.

[smcv]

I'll use two digits going forward

Closing, then. Thanks!

[MAN-AT-ARMS]

By the way...I don't think your package should require the libspeexdsp-dev package.

[smcv]

Ah, good point - possibly a copy/paste error from older ioquake3, which did use it. Dropped in git, thanks.