Start version/revision where?

Libraries and devices seem to need to start at version 1.1, not 1.0.

LIB_IS_AT_LEAST((struct Library *)RequesterBase,53,1)

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......

@mritter0

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).

@Chris

Quote:
Why 1 and not 0 ?

@TSK

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}

@TSK

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.

@xenic

You left out the comment field after the date.

\0$VER: <name> <version.revision> (mday.month.year) <comment>\0

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 /

@broadblues
Quote:
No I didn't because I said this:

"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:

In addition, the day,month,year are displayed in a different order by the Version command (month/day/year).

The version command uses locale.library to display the date, so it will be converted into the format specified by your settings.

Simon

More specifically your country settings, not your language settings (in case anybody was wondering).

Best regards,

Niels

Looks like 1.1 it is.

It makes sense to me.