Whats with the version number 53 point something everywhere?

Hi,

This has been bugging me for ages, its very lame, does not make sense when it comes to third-party software.

Take this for example, its the first compiled version ever, available on OS4Depot, hence logically it is version 1 or perhaps 1.01 etc... if there minor corrections.. but certainly not 53.x!!

http://www.os4depot.net/?function=sho ... printer/hp_photosmart.lha

Its not 53.1! Okay sure Workbench itself is version 53 or something, but this is completely insignificant and irrelevant even if it is planned to be included in the OS it should always be version 1.x - there is no logic here.

Ditch the pre-fix 53 - it makes absolutely no sense to anyone.

Some programs require OS4.1 so they have the version number 53.x to match the system they require to run. Which makes a lot of sense to me. Maybe because I lived through the 80's and 90's with a rom switcher where every program was 1.x and often fell foul of trying to run a program with the wrong kickstart loaded.

@djrikki
I have to agree. If they *do* ever decide to bundle it with OS4, then they can surely bump the version number to 53 then. No need to do so before then!

And I have to disagree... if they decide one day to bundle it with OS4.x, you suddenly have two nearly identical versions with different version numbers out in the wild.

I dont see any problem with a major version number of an application correlating to the OS major version number (its quite useful instead. So you could see if its meant to be used with OS4.1+ for example). But it has to be mentioned in the readme, which REvision was the initial one.

Hey, its only about where to begin with the counting. To start with 1 is convention only

This doesn't annoy me very much. However, I see a big problem with starting the version number "in sync" with the AmigaOS internal version numbers:
I release v53.1 of my library chris.library
I fix a few bugs and release chris.library 53.2
I then add a new function ChrisIsGreat() to my library. Because it is a new function, I then need to bump the version so programs can request the version with ChrisIsGreat() in it.
Suddenly, chris.library is at v54.1 and no longer in sync with the OS, and as a result the version number is meaningless and artificially inflated. Will it now only work with OS 4.2? No. Does it make it harder to integrate with the OS because it already has a higher version number? Yes. It could be bumped to v53 but can't be "unbumped" back to v53.

@Chris
I think I agree with you to some extent. A program should have it's own versioning sequence (1.0, 1.1 etc.) until it gets accepted as part of the OS distribution. At that time the versioning can be brought into sync with the current OS version number (50+) if the sources and all rights are contributed. Any subsequent releases outside the OS (e.g. an important bugfix released on OS4Depot) should increment the version or revision used in the OS. For example: If I release a program that has been revised up to v1.6 then when it is accepted into the OS it would become a 50+ version and any future releases inside or outside the OS would stick to that versioning scheme. What we don't want is versions released with the OS to have a 50+ version and subsequent revisions released elsewhere reverting to the original versioning (1.7, 1.8 etc.).

Actually, I don't think programs should be adopting the 50+ versioning schecm (like 53.2) unless the sources are released to the OS and can be maintained by OS developers. If it's just a binary contribution, the original version scheme should be retained. For example, SGrab is included with OS4 but remains at version 1.29. Maybe I'm wrong, but that indicates to me that it was a binary contribution and that the author retains the rights to the sources.

Since there are no enforceable rules or laws governing version numbers, an author could use a Roman Numeral version like: VII.XI if desired

@djrikki
I understand your irritation but I think you picked a bad example with the HP Photosmart driver. I think the person who released that file was "loaned" the OS4 Photosmart driver code so he could fix it. His fixed driver was accepted and included with subsequent OS releases. I don't think he is an official part of the Hyperion dev team but needed to indicate that his release is an improvement to the OS driver, not a completely different replacement.

I generally start with version 0.x for the initial skeleton materials, bumping to 1.x series when compilation produces something usable.

I then bump revisions based on how many milestones are passed.

If I were to do it based on changes alone then the count would be a seriously large revision number that would just be too ridiculous to release :)

but I do agree with the point about system sync being a waste of time (just document it already somewhere the users can get to easily!!!)

At first I thought it wasa good idea as it then matches the os version it's depending on, but Chris' example made me change my mind. It better to start with v 1.0 (even though it should be 1.1 )