ZapRedraw and ARMx6/mini.m

Until you find that 1.23beta47c > 1.23

Until you find that 1.23beta47c > 1.23

Which is exactly what I’d expect…

Oh, and ARCbbs, which used version numbering like that, used ‘ß’ instead of the word “beta”. Really, trying to programatically parse and figure out how people apply version numbers to stuff is the path to madness. Best to assume it is internally consistent and won’t do unexpected things like 1.22 → 1.23beta47c → 1.23 (this ought to be 1.24; as beta47c was a subversion of 1.23).

Does Store even need to care about version numbers?

Given that it just has one download for any application at any time, it just needs to record that you’ve downloaded a file and then warn you about a new version when that file is replaced by another. We have to assume that developers will only release new versions to Store if they want users to upgrade from the previous one.

care about version numbers?

Dates would work, but if they’re held in RISC OS format, it’s a five byte which makes comparisons harder (and the OS provides no functions for manipulating 5-byte time).

The benefit of versions is that, when treated as just a string, it follows a progressive sequence so a string comparison matching each byte against its equivalent in the other string will yield a valid result in the majority of cases.

If the time is held as YYYYMMDDHHMM, then that can be either turned into an long integer and tested, or directly string compared.

We have to assume that developers will only release new versions to Store if they want users to upgrade from the previous one.

Indeed, it’s a fair assumption. But we still need a means of telling them apart. ;-)

if they’re held in RISC OS format

Given that Store is connected to a internet-based backend, I’d hope that they’re running it on a more conventional database system. :-)

But we still need a means of telling them apart.

The thing with Store is that there’s only one file at a time. I’d assume that there’s a database table with details of the files (if not the files themselves), and each entry could easily¹ have a unique, numerical ID assigned in an incrementing fashion as new files are uploaded. If Store knows the ID of the file that you last downloaded for Zap Ultimate, the check is simply “is the ID of the current Zap Ultimate download greater than the ID for your last download”.

¹ In the sense that this is how databases often identify objects like this.

The server is Apache running PleskLin. The user visible paths on the site are “/exec/ps/<something>.aw”. Don’t know what .aw is, PlingStore is the only place I’ve seen this.
Trying some mad parameters doesn’t give any reply that indicates, so well done on sanitising inputs. ;-)

Well, look on the bright side, it’s not WebJames!

Best to assume it is internally consistent and won’t do unexpected things like 1.22 → 1.23beta47c → 1.23 (this ought to be 1.24; as beta47c was a subversion of 1.23).

You call that unexpected, but it’s exactly what I’d expect. The developer is getting ready to release 1.23, but decides to release a beta of it beforehand (or in this case, 47 betas!). It passes testing and is therefore formally released as 1.23.