I think there is what should be considered a bug in the AcornSSL module build process, because the module version and date are not changed when the module contents change only because the mbedTLS library has changed.

For example:
v1.04 has 3 different modules – for mbedTLS versions 2.16.0, 2.16.1 & 2.16.2.
v1.05 has 2 different modules – for mbedTLS versions 2.16.2 & 2.16.3.

So much of RISC OS operation depends on the version number being used in *RMEnsure commands and other checks, which cannot be used if this continues. As the base module code stabilises, probably the only changes will be mbedTLS ones.

What makes it worse is that the new modules generated because of mbedTLS library changes do not get listed in the ‘Recent changes’, or even in the AcornSSL module history at all.

While it is undoubtedly a massive improvement that mbedTLS changes can now be incorporated into RISC OS so quickly, please can the changes be made more obvious, both to us and to our machines?

It is perfectly feasible to have module versions 1.041, 1.042, 1.043 etc.

It is perfectly feasible to have module versions 1.041, 1.042, 1.043 etc.

Or even 2.160, 2.161, 2.162, 2.163 etc

See what I did there?
The delete key takes the second “.” out of the mbedTLS version quite nicely don’t you think?

I suspect that using n.nnn version numbers may cause other problems? Would RMEnsure still work? I think the Style Guide says n.nn should be used, but I do not have mine with me to check.

Using the mbedTLS version would solve the static version when mbedTLS changed … but the rest of the module may also change without mbedTLS changing, as they did between v1.04 and v1.05 for a bug fix. And is the mbedTLS version guaranteed to only be n.nn.n, or could it be n.nn.nn?

So I am afraid neither suggestion would get my vote!

If it changes, it’s not the same module. It doesn’t matter which bit changes, it is not the same module.

Bump the version number. It is not the same module, it should not have the same version.
Bump it.
The end.

<mic drop>

I think the Style Guide says n.nn should be used,

The DDE PDF version doesn’t mention RMEnsure at all.

However PRM1, in describing the module header, says: The version number contains three digits and a full stop, eg ‘1.00’.

Therefore:

is perfectly feasible to have module versions

Can this be demonstrated as working on all releases of RISC OS (save 2.xx)?

Edit – yes. https://www.riscosopen.org/viewer/view/apache/RiscOS/Sources/Kernel/s/MoreComms?rev=4.8#l574

Looks like the code is quite capable of dealing with 1234.5678 as a version number, so that ought to cover however many mbedtls incarnations happen in the lifetime of RISC OS.
And even more reason to back bumping the version number.

It’s just a number. Tradition and documentation both have two digits following the dot. There is NO reason to invent a different system for AcornSSL. NO reason AT ALL.

There is NO reason to invent a different system for AcornSSL. NO reason AT ALL.

Doubly so when the mbedTLS version is already listed alongside the module version when you do *Help Modules!

Doubly so when the mbedTLS version is already listed alongside the module version when you do *Help Modules!

So, RMEnsure and such can identify the difference then?

To quote Rick in Nemo mode:

If it changes, it’s not the same module. It doesn’t matter which bit changes, it is not the same module.

As to “Tradition and documentation” being a reason not to use clear distinction of ‘minor’ changes – phfft.

So, RMEnsure and such can identify the difference then?

No. Only the user can, by looking at the *Help Modules output. RMEnsure only uses the module version.

So, RMEnsure and such can identify the difference then?

No, but it shouldn’t need to. What I was attempting to say is that AcornSSL should follow normal module versioning (i.e. new version = increment the number) rather than doing anything special. In that case, RMEnsure will work just like it always does.

Along the same lines, I was also trying to dissuade “encoding” the mbedTLS version number in the module version number. If you, the user, need to know which version of mbedTLS it’s using then you can run *Help Modules.

All you need to know is whether it’s the same or different. The established numbering system does that perfectly well.

If a bug is fixed, it makes no difference whatsoever whether it was in mbedTLS or the RISCOSification code. Code change = change in behaviour = increment the version number. Simple as that.

If SysMerge can’t detect that a new AcornSSL version needs installing, then that’s a major problem. There’s no point regularly incorporating mbedTLS bug/security fixes into AcornSSL if the new module can’t automatically be rolled out to users.

Easiest solution would probably be to have AcornSSL refuse to build if the mbedTLS version doesn’t match the expected version. That way, whenever mbedTLS changes, we’d also be forced to change the “expected version” that’s in the AcornSSL sources, which will in turn trigger the usual .01 increment in AcornSSL version number.

What makes it worse is that the new modules generated because of mbedTLS library changes do not get listed in the ‘Recent changes’

At time of writing, the mbedTLS changes are 3rd in the list.

So much of RISC OS operation depends on the version number being used in *RMEnsure commands and other checks, which cannot be used if this continues. As the base module code stabilises, probably the only changes will be mbedTLS ones.

Conceptually I don’t see this as being different to when a bug in the C library gets fixed, we don’t bump all the C modules up by 0.01 for that. Likewise RISC_OSLib gets tickled which results in a bug fix to any components it gets used in (eg. MakeModes, Edit, etc). Same when a compiler bug is fixed – a whole new set of modules appear, possibly different binaries (if they happened to trigger whatever bug it was) but same versions. We also have several copies of the FPEmulator and Wimp in !System, all for different targets but same versions.

The key bit is, from your application’s point of view, the AcornSSL module still matches the minimum criteria (SWI/API-wise) of the RMEnsure so it should be fully compatible.

Or even 2.160, 2.161, 2.162, 2.163 etc
See what I did there?

Unfortunately because of the way the decimal counting system works that’d come unstuck resolving 2.123 whether that was 2.1.23 or 2.12.3

Along the same lines, I was also trying to dissuade “encoding” the mbedTLS version number in the module version number. If you, the user, need to know which version of mbedTLS it’s using then you can run *Help Modules.

Furthermore, you shouldn’t assume mbedTLS will always be the supporting library. It wasn’t for AcornSSL 0.xx which used OpenSSL, and looks like ARM are mulling rebranding it in future too.

If SysMerge can’t detect that a new AcornSSL version needs installing, then that’s a major problem.

Fortunately Ben (dammit when he’s right!) had the foresight to catch this exact case in Installer as far back as 1998. In the event of a tie for version numbers the newer date (stamp of the file) breaks the tie – hence any newer release of AcornSSL will always overwrite the existing.

Fortunately Ben (dammit when he’s right!) had the foresight to catch this exact case in Installer as far back as 1998. In the event of a tie for version numbers the newer date (stamp of the file) breaks the tie – hence any newer release of AcornSSL will always overwrite the existing.

That’s better than nothing, but I wouldn’t say it’s a cast-iron solution. It’s too easy for file timestamps to be lost or misleading.

That’s better than nothing, but I wouldn’t say it’s a cast-iron solution. It’s too easy for file timestamps to be lost or misleading.

Or even be changed by a user action using existing facilities in the Filer

Let’s just re-iterate the Nemo mode comment from Rick

It is not the same module, it should not have the same version.

Martin worried

I suspect that using n.nnn version numbers may cause other problems?

Starts like a statement and ends like a question. Not for the OS. Possibly for anyone who invented their own restrictions on version numbers based on what they thought they could see. RO is not immune to cargo cult programming.

Would RMEnsure still work?

Yes. Of course.

PRM1, in describing the module header, says: The version number contains three digits and a full stop, eg ‘1.00’.

Do you see what I mean about the historical quality of RO documentation? Risible.

Dave demanded

There is NO reason to invent a different system for AcornSSL. NO reason AT ALL.

Nobody has invented a new system. Just clarified the one you misunderstood. Confirmation bias is a terrible thing.

For the avoidance of doubt, the definitive statement is:

Module version numbers are 16.16 binary coded decimal numbers.

Please forward all further confusion on the matter to OS_Module 20 or every implementation of EMEnsure since RISC OS 2.

By which yardstick perhaps the best version numbering for AcornSSL would probably be:

(riscos-specific-build-number).(mbedtls-build-number) eg. 5.2163

However, I see this falling apart when mbedtls exceeds 4 digits eg. 2.16.13. Actually that’d probably be OK, because 16bits should give us 65535 numbers. But then perhaps 7.16.13 would be an issue.

Nemo, am I being thick?

You’ve missed the BCD bit, so it’s 10,000 not 65,536

Module version numbers are 0.0000 to 9999.9999, and be careful about signed/unsigned at the top end.

*Modules and *Help Modules suppress the last two fractional digits if they’re zero, which is what has led to confusion. Monkey see, monkey do.

An excerpt from *H.Mod. on my machine:

OSCommands      0.13 (01 Dec 2003)
FSCommands      0.061 (04 Sep 2019) © nemo 2019 (portions)
ModuleCommands  0.08 (08 Jan 2004)
...
HostFS          0.62 (01 May 2004) © Graeme Barnes
HostFSFiler     0.071 (11 Aug 2019) © Graeme Barnes 2009, © nemo 2009-2018
Internet        6.11 (17 Jul 2004) for Virtual Acorn © Graeme Barnes
...
SpriteUtils     1.19 (02 Dec 2003)
SuperSample     2.002 (30 Dec 2017) © nemo 2017 (portions)
System Devices  1.28 (03 Dec 2003)
TaskWindow      0.76 (04 Dec 2003)
Window Utils    2.51 (04 Dec 2003)
Filter Manager  0.261 (04 Dec 2003) © nemo 2018 (portions)
WaveSynth       1.16 (01 Dec 2003)
...
ROMPatch        0.14 (15 Mar 2004)
CallASWI        0.051 (27 May 2010)
SyncClock       0.10 (27 Feb 2002)
ZeroCLI         0.02 (25 Jan 2011) © nemo 2011
Deep Key Buffer 2.08 (14 Feb 2004) © Cerilica 1999-2004
Auto CLI space  1.02 (05 Sep 2019) © nemo 2019
CrashF12        0.02 (11 Aug 2019) © nemo 2018-2019
FixUpDown       1.00 (09 Dec 2010) © nemo 2010
ModuleCredits   1.02 (11 Aug 2019) © nemo 2011-2019
UTF8Alphabet    1.07α (31 Aug 2019) © nemo 2018-2019
VDUMode         0.01 (28 Sep 2017) © nemo 2017
WriteReg        1.04 (11 Aug 2019) © nemo 2002-2019
CloseHook       1.01 (13 Aug 2019) © nemo 2019 (thanks to Martin Avison)
CerilicaAlphabets       0.24 (21 Apr 2019) © Cerilica 2001-2019
TransTIFF       1.00 (27 Sep 1993) [nemo]

You will note that version numbers can be followed by other characters, so 1.23a is legal… but there’s no way for RMEnsure or OS_Module 20 to make use of the letters – they are informational only.

Installer however only reads the first 2 digits after the full stop so would see 5.2163 as 5.21, and if I understand the C code correctly it returns -1 if there is no full stop, so will not accept “17” as a valid version number, whilst RMEnsure does.

Then Installer is broken.

Ugh, Installer. That one commits a lot of sins. This very site includes a “current” !System download containing a 26bit version with a current version number. The same version (or higher) than 32bit ones. So, yes, you can update your !System and have Installer delete itself and replace a 32bit version of itself with a 26bit one, because the 32bit version in 500 folder is lower version than the 26bit one in the ROOL zip. And yes, that has happened. Recently. To some not-stupid users.

And people wonder why no-one uses Installer outside of Cambridge…

There’s a very strong argument for 32bit versions of Installer using a higher master-version number eg. 1.xx for 26bit versions and 2.xx ofr 32bit ones (or even 5.xx for 32bit ones). !System/Installer will allow older versions to exist “downwards” but not “upwards”, so 26bit versions for legacy OS builds should have a lower version number than 32bit RO5 builds.

Why wouldn’t Installer be agnostic? Doing different things on different OSes is not the same as needing to have different binaries on different OSes.

Nobody has invented a new system.

Erm, I think Sprow may have when replying to my n.nnn suggested format where he introduced the concept of more than one dot – which isn’t something I understood to be supported, hence me simply taking out one dot from the mbedTLS version string:

Or even 2.160, 2.161, 2.162, 2.163 etc
See what I did there?

Unfortunately because of the way the decimal counting system works that’d come unstuck resolving 2.123 whether that was 2.1.23 or 2.12.3

So, the n.nnn format is viable (as is n.nnnn etc for a limited number of repetitions) and we have the additional information that some old software (Installer etc) may be broken and require a fix.

By which yardstick perhaps the best version numbering for AcornSSL would probably be:

(riscos-specific-build-number).(mbedtls-build-number) eg. 5.2163

The temptation there is to see this as only applying to RO5.x (I’m not sure it does) and to head toward a module number of 527.2163 which covers the fact that the build is beta RO5.27 and the TLS is 2.163.
Which, is almost certainly, overkill