So why not programs? I have always done 1.0 as first release. But that doesn't always match it's custom libraries or locale catalogs if they start at 1.1, and increment with each new release.
Just one of those things you think of when standing at work bored......
Both version and revision numbers need to start at 1.
This only applies to internal version numbering, so if you want to call some piece of software Melted Candle v1.0 then you can do so... as long as the version reported by the "version" command is 1.1 (or higher).
The way I was brought up many years ago, 0.x was used for your alpha level versions (before it was complete and given to others).
1.0 was the first version that you gave to other people to test/play with.
I have stuck with that sequence for OS4 components, raising the version to 53 or 54 as soon as it gets to the beta testers.
It's all up to the author, really. If it's a translation or port from another platform, then you have to keep the old versioning system to avoid confusion about how up to date a port is.
@tonyw The old AmigaOS style guide doesn't seem to mention starting numbers for versions or revisions. It just specifies the format: $VER: <name> <version>.<revision> (<day>,<month>,<year>)
However, nowadays it seems anything goes; like: YAM 2.7 [OS4/PPC] (12/24/2011) Copyright (C) 2000-2011 YAM Open Source Team
You could include an original ported version too; like: $VER: MyProg 1.5 (24.12.2011) [OS4] {3.98.4}
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Because 1 is the number of the first version/revision and versions are not fractions (they are just version number and revision number separated by a dot).
BTW if you allow for a "zeroth" version/revision then the first version number should strictly speaking be "0.0" and not "0.1".
If you generate your version strings with bumprev it enforces the 1.1 starting point.
10.RAM Disk:> bumprev -v 0 -r 0 test bumprev: Illegal version "0" 10.RAM Disk:> bumprev -v 1 -r 0 test bumprev: Illegal revision "0"
If you create them by hand or some third party script you can get away with 0.1 etc but it's not technically a valid AmigaOS version number.
There are a number of prjects aout there that have historicaly used non standard version numbers AWeb is one as it adds a non standard third element eg 3.5.10
It's not the end of the world but if you want to verify versions with VERSION etc it can cause issues if the version string is non standard.
day and month must have no leading zeros (that can and does confuse Installer scripts, but I think C:version can cope with the leading zeros if present)
NOte the date parts in the string are seperated with dots, but wil be displayed by Version with /
"The old AmigaOS style guide doesn't seem to mention starting numbers for versions or revisions. It just specifies the format."
In the old "Amiga User Interface Style Guide" (second edition - pages 110 & 111) there is no comment field. Also, there is no comment field listed in the http://wiki.amigaos.net/wiki/UI_Style_Guide_Shell "Embedded Version IDs".
Maybe you found the version format containing a comment field elsewhere. Regardless, my point to Tony was that you can include the original version of a ported program after the Amiga version & date; especially if the comment field is now an accepted part of the Amiga 'Version' format.
Quote:
NOte the date parts in the string are seperated with dots, but wil be displayed by Version with /
In addition, the day,month,year are displayed in a different order by the Version command (month/day/year).
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
The version command uses locale.library to display the date, so it will be converted into the format specified by your settings.
Simon
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk