1

I have a small doubt regarding the software versioning, I know that there are many ways to do it, but the most common is with numbers and with a length of 3 to 4 digits, I know what each of the numbers mean in this method, my doubts are two but they go hand in hand (I clarify so that I do not cross out the question of unfocused / broad).

1. How should be the version of a software released for the first time?

I explain: Many times I have seen software that have as version 0.1 or 0.0.1, so how is this, should all software start from zero? However sometimes I have seen that the first version of others is 1.0.0.0. I read that there is no universal standard for software versioning but I imagine there are things to take into account and that explains why some developers start from 0.1 and others from 1.0 (Unless one of them is doing things wrong). In other cases I have seen that the versions are not totally followed, but for example, one is 1.10, and the next one is 1.15, that is, they do not increase from one or the other, but they do not increase from one to the other.

2. In case of an independent developer what length is recommended?

I explain: In the number method I saw two common forms which is the 3 digits and the 4 digits, but the fourth one was the "Number of deliveries/revisions", which changes when the product is rejected. That concept gives me to understand that only applies to companies that develop software and does not meet certain parameters, I do not know, then, that for independent developers is better to use the 3 digits mode.

I apologize if this is a long question, let's concentrate on the numerical method.I repeat, I know there is no standard for this but, I would like to know why there are so many ways of versioning on the internet and which ones are incorrect.

4
  • 1
    A 0.x version means it hasn’t been released to the public yet. If a fourth number is used, it is typically an automated build number. – John Wu Mar 9 at 1:00
  • @JohnWu What do you mean it has not been made public? The software I have seen with 0.x was already available for download. – Jalkhov Mar 9 at 1:03
  • 1
    It's not consistent. Especially when you consider things like beta testing and pilot testing, which are sort of open to the public but not really. Also, sometimes a pre-release version ends up getting released due to project concerns. Don't know what to tell you. – John Wu Mar 9 at 1:58
  • 3
    Initial versions can start with 0, 1, or >1, this is pretty arbitrary. I have seen first public releases of a product starting with, for example, 3.x, just for marketing purposes, to give customers an impression of some maturity. Or another product where version numbers 8.1, 8.2, 8.3, and 8.4 there was 8.10 to match the version number with Windows-10. Or look at the latest Windows versions 7, 8, followed by 10. Or look at version numbers of Win10 - mostly years and months. There is a lot of marketing going on here. – Doc Brown Mar 9 at 6:25
5

Versioning is highly opinionated. There aren't that many standards, but there are some conventions. For public APIs (such as web APIs or those provided in libraries), Semantic Versioning is a common convention and there are tools to enforce it. However, not all projects take advantage of it and it doesn't give much help to application developers.

How should be the version of a software released for the first time?

It depends on your application.

In Semantic Versioning, anything that starts with a 0 is to be considered unstable. Your unstable early releases, if you choose to make those public, would be of the format 0.x.y. Once your API stabilized, you would release 1.0.0 and proceed from there. However, as I mentioned earlier, Semantic Versioning only helps with libraries. You can try to model your versioning on this scheme, but I'm not aware of any documented conventions.

Technically, you don't need three (or four) point version numbers. You could use the date of build or release, random names, a single version number, or perhaps no version number at all. The Wikipedia article on software versioning gives several examples.

Some kind of consistency, or changing the versioning at a logical point in time, is important. Having something in your README about the level of development and maintenance would be a good idea. I would expect anyone using the software in a professional capacity to do their due diligence and assess the quality of third-party software that the use to support their development.

In case of an independent developer what length is recommended?

This is less of a concern about who is doing the development, but what type of software development is being done. API versus application is one way to think about development. Self-hosted versus SaaS for applications is another consideration. Thinking about the thing that you are versioning and what needs to be communicated to stakeholders is a good way to approach choosing a versioning scheme.

2
  • 1
    There are use cases where semantic versioning can be applied to an application. One in particular is when you have an editor that saves data to a file (EG project data) and an update changes the format of the saved data such that previous version can no longer open it. I was recently hit with this situation when I updated an application I use from version 9.5.18 to 9.5.23 and people who were still at 9.5.18 couldn't load my projects. What was surprising was that no one had ever previously seen this change in behavior with this application. Semantic versioning would have helped here. – Peter M Mar 9 at 13:17
  • 1
    @PeterM Semantic Versioning is designed for APIs. In your example of an editor, what do you do when you change the UI, for example? Perhaps do what Microsoft did in Microsoft Office 2007 and introduce a ribbon-style UI? Is that a major change or not? The formal definitions in SemVer don't say, since SemVer is designed for an API. So, like I said in my answer, you can look at SemVer as a model, but the formal specification doesn't handle applications. – Thomas Owens Mar 9 at 13:30
3

I know that there are many ways to do it,

That is correct. There is no International Version Number Police, everybody can do what they want, and more or less everybody does do what they want.

but the most common is with numbers and with a length of 3 to 4 digits,

I would disagree. The most common is with numbers, letters, and (abbreviated) words, and a length of 3 to 4 numerical components (which need not necessarily be single digits) and additional alphanumeric components. For example, 12.34.56.789-rc5 is not exactly uncommon to see.

I know what each of the numbers mean in this method,

No, you don't, precisely because "there are many ways to do it".

1. How should be the version of a software released for the first time?

Everybody can do whatever they want. There is no International Version Number Police.

I explain: Many times I have seen software that have as version 0.1 or 0.0.1, so how is this, should all software start from zero?

Every developer can choose whether to call the first version 0.1, 0.0.1, 1.0, or Fred. There is no International Version Number Police.

However sometimes I have seen that the first version of others is 1.0.0.0. I read that there is no universal standard for software versioning

That is correct. There is no universal standard for software versioning.

but I imagine there are things to take into account and that explains why some developers start from 0.1 and others from 1.0

Yes, there are things to take into account: one developer likes one way better, another developer likes another way better.

(Unless one of them is doing things wrong).

In order for one of them to do things wrong, there would need to be universal standard for software versioning that both are required to obey, otherwise the term "wrong" doesn't even make sense.

Since there is no universal standard, and everybody can do what they want, neither of them could possibly do things wrong, by definition.

In other cases I have seen that the versions are not totally followed, but for example, one is 1.10, and the next one is 1.15, that is, they do not increase from one or the other, but they do not increase from one to the other.

There could be hundreds of reasons for this. Since every developer can do what they want, they obviously also can skip versions for whatever reason they want.

Maybe they just like the number 15. Maybe 1.11–1.14 had some major security flaws and where thus rescinded. Maybe numbers ending in 5 have some special meaning in this particular developer's versioning strategy.

Some projects have "magic numbers" in their versions. For example, in some projects odd minor numbers are development releases and even minor numbers are stable releases. I.e. 2.11.x would be the x'th development release on the road to 2.12.0. In some other projects, minor numbers above 90 are development releases, i.e. 2.93 would be the fourth development release on the road to 3.0. Some really do get creative, and designate 90–94 as alpha versions, 95–98 as beta versions and 99 as the release candidate. (And then run into problems when there are more than 5 alpha releases, 4 betas, or multiple release candidates.)

2. In case of an independent developer what length is recommended?

The recommended versioning strategy for an independent developer is exactly the same as the recommended versioning strategy for every other kind of project: the one which best fits the project's needs.

I explain: In the number method I saw two common forms which is the 3 digits and the 4 digits, but the fourth one was the "Number of deliveries/revisions", which changes when the product is rejected. That concept gives me to understand that only applies to companies that develop software and does not meet certain parameters, I do not know, then, that for independent developers is better to use the 3 digits mode.

Every developer can choose whatever versioning strategy they want. If you don't like that one, then choose another.

A version number is simply a way to communicate "something" to "someone". You have to figure out what you want to communicate to whom. For example, Semantic Versioning is designed to communicate API compatibility to a machine. On the other hand, "Microsoft 365", for example, is a version number that is designed to communicate a marketing idea to end users.

I apologize if this is a long question, let's concentrate on the numerical method.I repeat, I know there is no standard for this but,

That is correct: there is no standard for this.

I would like to know why there are so many ways of versioning on the internet

Because there is no standard for this.

and which ones are incorrect.

None, because there is no standard for this which could say what "correct" even means.

As mentioned above, Semantic Versioning is a versioning strategy that has become somewhat popular recently. But it is only really useful for versioning libraries, modules, frameworks, etc. that have a well-defined public API.

It is also important to realize that a product doesn't need to have only one version number. The purpose of a version number is to communicate something to someone. If you have more than one thing that you want to communicate and/or more than one audience, then you can have more than one version number.

For example, Windows "Vista" was the "marketing version", but it also has an "engineering version" which is 6.0. Windows "7" was the marketing version, but the "engineering version" was actually 6.1. Windows 8 was 6.2, Windows 8.1 was 6.3, Windows 10 is 10.0 for all versions of Windows 10. So, "Windows 10 Version 1507" has the same version number 10.0 as "Windows 10 Version 20H2", even though they have bigger differences than Windows 8 and 8.1.

Android has a letter, a code name, a marketing version, and an API version. The letter, the code name, and the marketing version are targeted at end users, the API version is targeted at app developers. Ubuntu has a code name and a marketing version, which is actually just the projected release date.

2

Context

It reigns supreme here.

  • Certain package managers mandate a specific versioning scheme at least for the packages released through their channels.
  • Certain Development tools will auto-manage version information in a particular scheme for you, making it much easier to use that scheme over another scheme.
  • Certain groups of users will prefer one or another versioning scheme. Like most lay conversation will discuss Program 2018 rather than build 10.3.2.1351, where as a developer is much more interested in the specific sha of the commit.

As for 0.x it depends.

  • Some schemes like semantic versioning treat it as a prototype release before a formal release (1.x).
  • Some schemes treat it as just the first version (many open source libraries do so, and can stay this way for years/decades)
  • Some schemes skip it all together

As for doing it right or wrong? Your only doing it wrong if you cannot identify the exact source, dependencies, and specific build of those into a binary format.

It would help though, if you:

  • identify the scheme being used.
  • explain how two different version numbers publish map to each other. Assuming you have to release in different version schemes.
  • be consistent in following your versioning scheme.
  • use a scheme that communicates meaningfully with your audience. Be that by using dates, or a composite version number like x.y.z

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.