How do you know which version number to use?

Question

Here I always wondered ...

Please excuse my naivety, but ... How do you determine what version number is for the name of your software?

I assume that when someone creates the "final" version of the application / program, is this version 1.0? - Then, what happens when you update it, as you decide to call it 1.1 or 1.03, etc.

Is this mainly for the developer?

Answer 1

I recently heard a more serious versioning strategy that I first encountered in Eric Elliot Medium account . It is more balanced than the version of the library, which is related to version numbers, but has the advantage of simplicity. Use a three-part version number, where each number means:

breaking.feature.fix

• violation : something has changed, which means the code / expectations must change.
• : Something new has been added, but the old code / expectations will still work fine.
• fix : nothing new, but bug fixed.

I leave my old answer below, as it still relates to client side versions.

---

I am inclined to weight significant figures as follows.

wxyz (or w.xyz)

• w - The basic version, with many new features. Paid update. The first public release of the software is 1.X (preliminary versions of version 0.X)
• x - Significant release, but without innovative new features.
• y - Bugfix Releases
• z - Patchlevel releases (crash fix, possibly only for one client).

If you decide to use w.xyz format, you will get only 9 digits before overflow. However, if you release this often, you may have a big problem.

Let me illustrate FooApp, my new product!

• 0.9 - First public beta
• 0.91 - Second Public Beta
• 0.911 - Emergency Beta for Crash Fixing on Motorola 68010
• 1.0 - First public release
• 1.1 - Added new BlahBaz feature
• 1.11 - Bug fixes
• 2.0 - A completely redesigned interface.

Answer 2

Jeff Atwood has a blog post about this, where he advocates using dates only and does not confuse the user with version numbers. However, he does discuss Microsoft's approach: Using dates to determine version numbers. He takes up a lot of space in his post, so I will not duplicate his work here. As for the version:

Versions (at least in .NET, go something like this):

1.2.3.4 where:

1 is the main release
2 - junior graduation
3 - build number


4 - version

The main release - means a "complete" system with any features that this version should have. Usually, any subsequent “major” versions are overwrites or architecture changes or (sorry for the redundancy) major software changes.

Small issue . This means a less significant release, possibly bug fixes, added small functions, or any number of other "minor" events. This may include interface changes and additions. Typically, applications should be somewhat compatible in their “main release,” so the minor versions of the same main release should be architecturally the same.

Build number As a rule, these are just bug fixes, small corrections and somewhat insignificant in scope. It may be something as simple as changing the contrast between the front and back of the application. Builds are generally internal designations, such as nightly builds, so you always have a place to get back to what's stable.

Revision number - means when errors are fixed, or VERY minor improvements. Usually they are reserved only for bug fixes - they do not include major feature enhancements as revisions .

Answer 3

We assign each assembly to any unique four-part application number defined as Major.Minor.Maintenance.Build .

Main - The main number is associated with significant changes in the application. This number also determines compatibility with other applications in the same package. This number increases as new releases are created. This usually means that major architectural changes have occurred.

Insignificant . A small number is associated with new functionality and bug fixes. At any time when new functionality is introduced or when correction of a correction error is applied, this number will be expanded and the service number will be set to zero.

Maintenance The maintenance number is associated with bug fixes. This number will be available on every release that contains bug fixes without interruption.

Build . The build number is associated with the subversion change set (version number) from which the application was compiled. This will provide an easy way to map version numbers to the exact code set in subversion.

The only number that developers are really interested in in this scheme is Build . number. By associating the assembly number with the revision number of the subversion, we can guarantee what code was used to create the released application.

Answer 4

I think the Linux kernel is a good reference for this:

The Linux kernel version number currently consists of four numbers, following a recent change, the long-standing policy has a three-fold version control scheme. To illustrate, let it be assumed that the version number is composed as follows: ABC [.D] (for example, 2.2.1, 2.4.13, or 2.6.12.3).

* The A number denotes the kernel version. It is rarely changed, and 

only with significant changes to the code does the concept of a kernel arise. It was twice changed into the history of the kernel: in 1994 (version 1.0) and in 1996 (version 2.0).

 * The B number denotes the major revision of the kernel. o Prior to the Linux 2.6.x series, even numbers indicate a stable 

that is, one that is considered suitable for production, for example, 1,2, 2,4 or 2.6. Odd numbers have historically been development releases such as 1.1 or 2.5. They were for testing new features and drivers until they became stable enough to be included in a stable release. It was an even / odd version of the number circuit. o Starting with the Linux 2.6.x series, there is no significance for even or odd numbers, with new development functions in the same series of kernels. Linus Torvalds said it will be a model for the foreseeable future.

 * The C number indicates the minor revision of the kernel. In the old 

a three-dimensional version control scheme, this was changed when security fixes, bug fixes, new features or drivers were implemented in the kernel. With however, the new policy, however, is changed when new drivers or features are introduced; minor corrections processed by number D.

 * AD number first occurred when a grave error, which required immediate 

met in 2.6.8 NFS code. However, there were not enough other changes to legitimize the release of a new minor version (which would be 2.6.9). So 2.6.8.1 was released with the only change being a fix for this bug. As of 2.6.11, this has been adopted as a new official version policy. Bug fixes and security fixes are now managed on the fourth number, while more changes are made only in minor version changes (number C). The D number is also associated with the number of times that the compiler has built the kernel and is thus called the "build number".

In addition, sometimes after the version there will be several more letters such as "rc1" or "mm2". "Rc" means release the candidate and indicate an unofficial release. Other letters are usually (but not always) the initials of a person. This indicates the branch of development of the nucleus of that person. for example ck stands for Con Colivas, ak stands for Alan Cox, while mm stood for Andrew Morton. Sometimes letters are associated with the main development area of ​​the branch from which the kernel is built; for example, wl stands for wireless assembly of network tests.

From http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

Answer 5

No matter which numbering scheme you choose, it is important to clearly indicate to users when the new version is compatible with the old client code and when the new version requires changes to existing customers . Most of the projects that I know have the very first number when the client code should change.

Besides compatibility, I also think that they talk a lot about how to use dates. Although it gets embarrassing if, like me, your biennial release schedule (but this is for an instrument first released in 1989).

Answer 6

Abcd

• A: 0, when beta, 1 at the first release, more than 1 for almost all correspondence.
• B: new features added.
• C: bugs fixed.
• Version Control Repository Version Number

Answer 7

This is what I use for modules in embedded C projects:

1.00 - Initial release

1.01 - Small revision
No interface changes in the module (i.e. the header file has not changed). Anyone who uses my module can upgrade without fear of code breaking. Maybe I did some refactoring or code cleanup.

2.00 - Main audit
The interface of the module has been changed (i.e. Functions added, removed or functionality of some functions). Upgrading to this version is likely to break existing code and require code refactoring using this module.

I must add that this refers to the development stage, that is, to the internal releases of modules into the project.

Answer 8

To add all the explanations given above, I suggest using a version control scheme that is easy for your customers to remember and easy for you to navigate and manage software versions. In addition, if you support various structures such as .Net 1.0, .Net1.1, etc., make sure your version control scheme also takes care of this.

Answer 9

Most likely, someone from sales or marketing will decide that they need some kind of buzz. This will determine if the next release will be 1.01 or 1.1 or 2.0. The type of work is the same with open source, but it tends to be tied to an unusual new feature that the team is proud of.

Answer 10

some good info here .

When to change files / build versions

When to change files / assembly versions First of all, file versions and assembly versions should not coincide with each other. I recommend that file versions change with every build. But, do not change the version of the assembly with each assembly, so that you can distinguish two versions of the same file; use the file version for this. The decision about when to change assembly versions requires some discussion of the types of assemblies that need to be considered: shipping and delivery.

Non-Delivered Assemblies In general, I recommend that you keep non-shipping versions of an assembly the same between shipping assemblies. This avoids problems with loading builds caused by errors due to version mismatches. Some people prefer using a publisher policy to redirect new versions of an assembly for each assembly. However, I recommend against this for non-shipping assemblies: it does not avoid all loading problems. For example, if a partner x-copies your application, they may not know whether to set the publisher policy. Then your application will be broken for them, although it works fine on your machine.

But if there are cases when different applications on the same computer must communicate with different versions of your assembly, I recommend providing these assemblies to other versions of the assembly so that you can use the correct one for each application without using LoadFrom / etc.

Delivery of the assembly As to whether it is a good idea to change this version for the assembly, it depends on how you want the binding to work for end users. Do you want these assemblies to be side by side or in place? Are there many changes between the two assemblies? Are they going to break some customers? Do you care if this violates them (or do you want to force users to use important updates)? If so, you should consider increasing the build version. But, again, think that doing this too many times may interfere with users' drives with outdated assemblies.

When you change your build versions To change hard-coded versions to new ones, I recommend setting the variable to the version in the header file and replacing the hardcoding in the sources with the variable. Then run the pre-processor at build time to install the correct version. I recommend changing versions immediately after shipment, and not immediately, so that there is more time to catch errors due to changes.

Answer 11

In the case of a library, the version number tells you about the level of compatibility between the two versions and, therefore, how difficult the update will be.

A bug fix release should support binary, source, and serialization compatibility.

Small releases mean different things for different projects, but usually they don’t need to maintain compatibility with the source.

Major version numbers can break down all three forms.

I wrote more about the rationale here .

Answer 12

It depends on the project. below is the haskell version control policy.

 -- The package version. See the Haskell package versioning policy (PVP) -- for standards guiding when and how versions should be incremented. -- http://www.haskell.org/haskellwiki/Package_versioning_policy -- PVP summary: +-+------- breaking API changes -- | | +----- non-breaking API additions -- | | | +--- code changes with no API change version: 0.1.0.0