: What are some standards in naming a software/hardware version? I am wondering if how we name a version of a spacecraft differs from how we name a version of a software. For software, I usually

The other answers have covered software numbering thoroughly, so I'll skip right to spacecraft.

You get a wide variety of naming patterns for spacecraft, but generally not the 1.2.3.1234 style numbers currently popular with software.

Here's some examples:

SpaceX:

Falcon 1 - the 1st Falcon model, and has 1 engine in its first stage.

Falcon 9 - the 2nd Falcon model, has 9 engines in its first stage.

Falcon 9 Block 5 - the 5th major design revision of the Falcon 9.

Falcon Heavy - a heavy lift variant of the Falcon 9.

ULA:

Thor-Alpha, Thor-Beta, Thor-Gamma, Thor-Delta - rocket designs that used a Thor missile as their first stage

Delta II, Delta III - successors to the Thor-Delta

Delta IV Medium - a Delta IV Small was proposed but never built.

Delta IV Medium+ (4, 2) - can lift a little more than a vanilla Delta IV Medium, with a 4 meter payload fairing and 2 boosters.

Delta IV Medium+ (5, 4) - Delta IV Medium+ with a 5 meter payload fairing and 4 boosters.

Delta IV Heavy - a heavy lift variant of the Delta IV.

Atlas V 401 - an Atlas V with a 4 meter payload fairing, 0 boosters and a 1 engine second stage.

Atlas V 551 - an Atlas V with a 5 meter payload fairing, 5 boosters and a 1 engine second stage.

Blue Origin:

New Shepard - goes to space, like Alan Shepard

New Glenn - goes to orbit, like John Glenn

New Armstrong - goes to the moon, like Neil Armstrong

---

(0)

Just to add to this list, a common method is "semantic versioning". There's a Wikipedia article explaining it which is worth reading. It's widely used where multiple components and dependencies are involved.

Another method (used by Microsoft) is Major.Minor.dateA.dateB. The build date and time is encoded in the last two fields. When a new version is built to fix a bug it automatically gets a version number higher than the previous version of the same component. Typically the combination of major and minor version determine compatibility.

And of course there's marketing versioning: 3, 3.1, 95, 98, NT, 2000, XP, 7, 8, 8.1, 10... whatever will sell a new version of your product.

Moving toward aerospace:

Spitfire Mk 1 to Mk IX...

Saturn ... Saturn 5

Soyuz 1..n, Apollo 1 .. 17 etc.

(Arguably these are mission names aa much as spacecraft versions)

---

(0)

Software numbering

There are lots of schemes in use, and sometimes software vendors even switched between schemes.

The most important feature of numbered schemes (as opposed to pure naming schemes like "Windows ME, XP, Vista") is that the version numbers always increase, that is, later versions get greater version numbers (what "greater version number" means however depends on the chosen numbering scheme).

For numbered versions, there are four main concepts:

The "integer" concept: The version is just numbered 1, 2, 3, ...

This, however, is pretty rare, because it doesn't give you a way to distinguish between large and small updates.
The "floating point" concept: This is a straightforward extension to the integer version, where the version number is treated as a floating point value.

I don't know how much it is used these days, but it was the prevalent way to version DOS and early Windows software. For example Windows version 3.0 was followed by version 3.1, which then was followed by version 3.11, where the change only in the second digit signified that it was a very minor update. On the Chinese market, there also was a Windows 3.2, which was released after Windows 3.11, thus demonstrating the floating point nature of the version number.

Another interesting case of floating point versioning is TeX, whose version number converges to pi. This is to indicate that the current version is basically stable, and only bug fixes are done.
The "list of integers" concept: This treats the version number as a lexicographically ordered list of integers. The first integer is known as major version number, the second as minor version number. A third number, if it exists, usually denotes pure bug fix releases. In rare cases there may even be a fourth number (for example with gcc, there were versions 2.7.2.1 to 2.7.2.3).

In this scheme, the major version number is 1 for the first release (usually pre-first-release versions are given the major version number 0). The next version always increases one of the numbers by one (selected depending on the size and/or importance of the update), and sets all following version numbers to 0.

Software using this scheme often omits trailing 0 values, with the exception for the minor version, which is almost always given even when zero.
Date based concepts: The version number indicated the time of release, like Windows 95, 98 and 2000, as well as Ubuntu's year.month numbering scheme.

Note that the used concept affects the ordering of the releases: Following the floating point concept, Windows 3.11 was released earlier than Windows 3.2, while due to using the integer list concept, Linux 3.2 was released before Linux 3.11 (with Linux 3.3 to 3.10 in between).

Spacecraft numbering

From what I gather from browsing this site, the most common scheme for spacecrafts seems to be just the craft's "family name" followed by an increasing number. Sometimes there are letters instead of numbers (like CRO A, CRO B, CRO C), or combinations of both (like Astra 1-B).

---

(0)

Software version numbers tend to be company or endeavor specific as @JonStonecash covers nicely.

A few examples:

Ubuntu releases their Linux distribution twice a year in April and October and uses a date format of YY.MM, but they also use fanciful names going up the alphabet such as Bionic Beaver for 18.04.

I have a tiny project of my own which is currently at version 0.3.1.1.
It's roughly Version.Release.Update.Patch.

When the version changes, one can expect that backward compatibility with older versions may be broken. Something is different.

The release changes when a lot of fixes and enhancements have been made. It's still the same product, but it may have new features or even old features removed or perhaps a new way of doing an existing function.

Update changes when significant changes have been made - primarily internally - but nothing that changes the nature of the product.

Patch changes five minutes after the last update when I realize I screwed up some text messages or broke something in the last update that I didn't notice before releasing it. A patch generally addresses one or a few small fixes to existing functionality.

The leading zero version is often used by projects that don't claim to be finished products (as in initially feature complete and everything nominally working).
Some projects (like mine) stay at version 0 for years even though they work quite well.

Then, you have people like Mozilla (Firefox) who seem to change the version number after just a few patches. They pretty much skip what I'm calling releases and updates.

The only things that are really important are to let the users know what your numbering system means and to be consistent with it so they know what to expect and can more easily decide whether they need to install the new package right away or can wait for a more major release later and when they do choose to install it, do they have to watch out for things that may not work the way they used to.

---

(0)

I developed software for many decades for several organizations. The standards for versioning were varied, but there are some general guidelines that most of them followed.

I will call the leftmost number in the version identifier, the Version. The releasing organization will change this number when there are major changes in the feature set of the software. Often these changes make parts of the new version incompatible with the older versions; features may be added, changed or dropped.

The next number to the right in the version identifier is typically the Update. An update may add features or fix problems or improve performance but it almost always upward compatible. There can be more than one update per version.

I will call the next number in the version identifier the Release. Depending upon the formality of the build and release mechanisms, the organization may package the software multiple times, running tests of all kinds internally, before letting it out into the wild. Each instance of these packages must be distinguished from each other with a different Release number.

Some organizations will number each build within a release or version. A build typically compiles properly but may fail before it is bundled into a release package. Some treat the act of compilation as the first cycle of tests. Modern languages often have substantial declarative redundancy. Compiling such software can reveal inconsistencies. For example, the programmer declared that the variable CountOfMonteCristto must hold an integer but there is a line of code that is trying to store a string into it. The compiler reports an error; the developer must resolve the issue. Many other compiler level tests might discover issues.

But there are large variations on these practices. Some organizations only use two levels. Others use four but only show two to the outside world. Some use fanciful names. Pretty much anything you do in this area will be justified.

I will note that you might want to use the format of the version identifier as a signal of character of the culture of the organization. The organization that releases BitBuzz 12.4.79.189245 is very much different from the organization that releases the Black Dahlia version of FlowerPower.

---

(0)