For what software? Certainly not any I use, nor the various versions of MS-DOS from the company in question I used back in the 80s and 90s.
Back from the 60s one heavily used convention was: [major-version] dot [minor-version] dot [revision]
The dots are separators not unlike those in an IP address, not decimal places (of which more then one of doesn't make much sense)
Within the same major-version number the API would remain backwards compatible. New commands may be added in, but old existing commands should both still exist and still function identically.
Within the same minor-version (rev changes) the API would remain identical and data/file formats would keep the same structure.
This would allow the operator to assume a revision update can be installed at will and not worry much about breaking compatibility for anything not listed in the change log.
One could also assume any additional applications made to work with the upgrading app should still function without modification, at least if you follow the API docs and don't do anything too hacky.
For minor-version updates you assumed API using additions and apps should still work, but anything hacky by-passing the API due to limitations needs revisited and possibly edited.
An example is one program that creates input to the program in question via documented API calls should be fine, but your second program that is run after output being generated that goes to parse internal data files you "shouldn't" be touching likely will break until updated to parse the new data file structure.
For major-version updates, all bets are off. Pretend it is a brand new app and all interaction with it by other system components may need redesigned or be obsoleted.
Of course version numbers are only conventions. Those conventions can be changed to mean something more fitting for your particular software.
Or simplified to "Start at 1.0 and keep adding one" if you can predict not many updates being needed or for very simple one-off script type things.
Dates have turned out to be quite convenient version numbers with the time making a good developer compile/commit identifier that already keeps revisions in the correct order.
The only real rule is "pick a convention and stay consistent for the life of that software, else the wrath of dragons upon your head be"