Mulab 8

[pljones]

With your logic, .311 would be the more recent version, not .32.

Yes. This isn't Reaper, so why would their versioning apply?

[e-crooner]

Rolling versions (date based) work well for subscription or rolling release software, but not for software with development cycles such as Mulab. Take for example the common YYYY.MM version scheme. What's the difference between 2019.12 and 2020.1 ? Well, the difference could be a bug fix, or a major version release. There's no clear indicator of a feature boost. Now, for software that's under a development cycle built on incremental upgrades instead of major feature boosts, the progressive model works. Mulab however doesn't exactly have the resources for a progressive/incremental development cycle as there is only one developer.

With regards to Reaper, it's currently in version 5.983, yes? What happens after 5.999? 5.9991? That last one seems like the improvement is more marginal than a full .001 update, which is more likely. The developer would have to plan out each release or plan out how many releases they can build under a major version, which is a strange artificial limitation.

I think the better lesson here is that versioning is a game between informing users about a new version, and how big the new version is. The rolling/progressive versioning schemes are great for knowing what's newer, but fail to inform users at a quick glance about the feature increases. On the other hand, Major.Minor.Build schemes are more difficult to read for what's newer, but do a much better job at informing the user the kind/how big of update it is.

No, I am not advocating date-based version numbering at all. I just mentioned dates because they also use delimiters and at the same time for instance 04 instead of 4. I like that.
Mulab is a tiny project, I think the format x.y.zz would be fine. The main number x is ok without a leading 0 as there is no delimiter before. y will never get beyond one digit anyway.

[e-crooner]

With your logic, .311 would be the more recent version, not .32.

Yes. This isn't Reaper, so why would their versioning apply?

I just mentioned Reaper (which is also inconsistent in my view) because it shows that there is no binding format, so adding a zero would not violate versioning rules.

Anyway, it was merely a suggestion...

[pljones]

y will never get beyond one digit anyway.

Maybe. Hasn't done yet (7.7.x is the highest I can see) but that's close enough that 10+ isn't improbable, let alone unlikely. Basically, each part of the schema is "just a number" - nice and easy to follow. Microsoft even gets Windows Explorer to sort them in the right order. It can't manage that with Reaper (where, as you've pointed out, 597 is higher than 4591). So, it seems far more sane the way it's done by MuTools to me.