Gazelle wrote: I also think that the leading zero for day or month is not required.
While bumprev doesn't supply them, and the internal locale routines don't specifically require them either, it is workable to leave them out, although the specified standard stipulates that the day and month are two digit. If it really bothers anyone, send the code to me and I'll add the two zeros to save them the bother :P
Quote:
And a leading zero infront of the revision does mean a subrevision eg like the AmigaOS: 2.0 -> 2.04 -> 2.05 ->2.1
Maybe this was dropped again after release 2.1
I very much doubt that this was part of the version string standard (my reference material is not available to check), and is certainly not applicable by todays standards. The above numbering system implies a decimal number, which would follow the numerical sequence. Version strings do not follow the decimal notation for their version and revision.
I forgot to thank you for making the documentation, so thanks.
I'm just nitpicking to get it even better :)
Quote:
from ADCD_2.1:NDK/NDK_3.1/Docs/tutorials/V38_V39_OS_Changes:
[...] Following the revision number comes a space, and then the date. The date is specified in numeric form only, with no leading zeros on any of the components. [...]
And you're right:
Quote:
Leading Zeros. Leading zeros are not supported as part of the version and revision numbers. So "2.04" is not a valid version/revision pair as far as the version command is concerned.
Maybe it's also worth mentioning:
Quote:
<name> can NOT contain any spaces. You can use underscores to achieve a similar effect.
And a leading zero infront of the revision does mean a subrevision eg like the AmigaOS: 2.0 -> 2.04 -> 2.05 ->2.1
I very much doubt that this was part of the version string standard (my reference material is not available to check)
You're absolutely correct, Commodore had a dual version numbering policy, where OS releases would be numbered as version . major-revision minor-revision. Internal version numbers would always be the incrementing version . revision format.
In OS release terms, 2.1 comes after 2.04. In internal version numbering, 2.04 (=2.4) comes after 2.1.
Of course this is still in place with OS4.
I tried the same dual-numbering system with Wet but nobody understood it!
Software originally targeting other OS'es, such as Linux, often use a version format that is alien to the Amiga version format. Don't use the alien format inside Amiga version strings. Instead create a new version string that represents the version.revision of your port.
I disagree whit this, how do you know witch version you have ported from if you do not use the Linux version number?
and how do you write version 2.20.4 in Amiga format?
This makes me think that AmigaOS does not have flexibility we need for version numbers.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
You can't do that since then all version tools will go bananas and suddenly we can't use stuff like version checks on libraries etc.
Amiga version strings should stay Amiga version strings and nothing else. Alien/Linux version strings would have to be handled in some other way. Just embed another cookie* in your software or use the amiga version string comment field.
Messing up the amiga versioning system is not the way to go.
* such as "\0$EXTVER 1.1.2 (5.9.2008) a comment\0"