Remember this is an Alpha version meaning it is not deeply tested and has a lot of things that doesn't work yet like all options and deep error checking.
But if a proper Extversion cookie has been place in a file like: "�$EXTVER: programname version.revision (dd.mm.yyyy) comment�" (with leading and trailing zero character, � is a zero character)
it will find it with this command from shell like: 1> extversion programname
and output: programname version.revision (dd.mm.yyyy) comment
So what is left (except fixing bugs): * implement some options * more error checking * tidy up the code (to meet some guidelines and make a few more code comments) * finish the documentation * possibly a simple installer * etc etc.
Hint: You can test the extversion file on itself, it has the EXTVER tag, like: 1> extversion extversion
I trust you can do version compares against this new string as well? Which wouldn't be possible if the "non-Amiga version" was just in the comment part of the usual $VER string.
The quoted format in the quoted test in the original post looks very like a standard amiga version to me, hence my question
@Chris
Version testing on a non standard version format would be quite tricky though. You could assume it's always in linux format vers.rev.subrev but many foreign apps don't stick to that rule either.
[edit] bad grammar even by *my* typing standards [/edit]
The quoted format in the quoted test in the original post looks very like a standard amiga version to me, hence my question
I agree, not the best example in the test quoted. I try to give a better example next time.
The point is to store a non Amiga version (f.ex. a Linux version) along with the "normal" Amiga version. So you have both the $VER: and $EXTVER: in a binary at the same time.