Operating System Version

The Version API Helper functions are used to determine the version of the operating system that is currently running. For more information, see Getting the System Version.

The following table summarizes the most recent operating system version numbers.

Operating system	Version number
Windows 10	10.0*
Windows Server 2019	10.0*
Windows Server 2016	10.0*
Windows 8.1	6.3*
Windows Server 2012 R2	6.3*
Windows 8	6.2
Windows Server 2012	6.2
Windows 7	6.1
Windows Server 2008 R2	6.1
Windows Server 2008	6.0
Windows Vista	6.0
Windows Server 2003 R2	5.2
Windows Server 2003	5.2
Windows XP 64-Bit Edition	5.2
Windows XP	5.1
Windows 2000	5.0

* For applications that have been manifested for Windows 8.1 or Windows 10. Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2). To manifest your applications for Windows 8.1 or Windows 10, refer to Targeting your application for Windows.

Identifying the current operating system is usually not the best way to determine whether a particular operating system feature is present. This is because the operating system may have had new features added in a redistributable DLL. Rather than using the Version API Helper functions to determine the operating system platform or version number, test for the presence of the feature itself.

To determine the best way to test for a feature, refer to the documentation for the feature of interest. The following list discusses some common techniques for feature detection:

• You can test for the presence of the functions associated with a feature. To test for the presence of a function in a system DLL, call the LoadLibrary function to load the DLL. Then call the GetProcAddress function to determine whether the function of interest is present in the DLL. Use the pointer returned by GetProcAddress to call the function. Note that even if the function is present, it may be a stub that just returns an error code such as ERROR_CALL_NOT_IMPLEMENTED.
• You can determine the presence of some features by using the GetSystemMetrics function. For example, you can detect multiple display monitors by calling GetSystemMetrics(SM_CMONITORS).
• There are several versions of the redistributable DLLs that implement shell and common control features. For information about determining which versions are present on the system your application is running on, see the topic Shell and Common Controls Versions.

If you must require a particular operating system, be sure to use it as a minimum supported version, rather than design the test for the one operating system. This way, your detection code will continue to work on future versions of Windows.

Note that a 32-bit application can detect whether it is running under WOW64 by calling the IsWow64Process function. It can obtain additional processor information by calling the GetNativeSystemInfo function.

Нумерация версий программы

У многих начинающих разработчиков возникает вопрос: как назначать версию своей программы?

Поделюсь своим опытом.

Не буду вдаваться в теорию, тем более, что жестких рамок в данном вопросе нет. В своей практике я встречал много различных вариантов назначения версий программ.

Приведу несколько примеров написания версии:

Разберем каждое значение.

Ревизия (Revision)

Номер ревизии (revision) в системе управления версиями (Version Control System, VCS или Revision Control System). Благодаря ему, можно легко получить исходный код конкретной версии, выгрузив его из хранилища. Как правило, данное значение начинается с 1 с последующим увеличением соответственно номеру ревизии и никогда не обнуляется. В силу того, что значение важно только для разработки, в нумерации программы его часто опускают.

Билд (build)

Иными словами, номер сборки программы. После изменения в коде программы, как правило, проводят сборку программы, т.е. полную компиляцию всех файлов проекта. Как правило, данное значение начинается с 1 с последующим увеличением соответственно номеру сборки. Обнуление сборки либо не проводят никогда, либо при смене мажорной (major) версии. В силу того, что это значение важно только для разработки, в нумерации программы его часто опускают.

Патч или заплатка (patch)

Значение изначально устанавливается в 0 и увеличивается по мере внесения незначительных изменений в программу, например исправление какой-либо ошибки. Обнуляется при смене мажорной или минорной версий.

Минорная версия (minor)

Значение изначально устанавливается в 0 и увеличивается по мере внесения существенных изменений в программу, например, добавления нового функционала в программу. Значение также может повышаться при накоплении мелких изменений (патчей). Обнуляется при смене мажорной версии.

Мажорная версия (major)

Собственно говоря, это и есть версия программы. Значение мажорной версии устанавливается равной 1. Увеличивается данное значение с выходом новой версии, когда происходят значительные переходы в функциональности, например, добавлены новые функции, существенно меняющие возможности программы, изменен интерфейс, переписаны основные алгоритмы и т.п. Значение также может повышаться при накоплении серьезных (минорных) изменений.

Для пред-релизных версий используют значение равное 0, получая номер вида 0.9.*.*

Год.Месяц.День (year.month.day)

Такое назначение версии указывает на дату выхода программы, что удобно для конечного пользователя. Исходя из такой нумерации пользователь может судить о том, как давно вышла конкретная версия программы, и не пора ли проверить обновление. К сожалению, подобная версионность не всегда удобна для разработчиков, особенно когда над проектом работает не один человек.

Кроме указанных позиций, разработчики часто используют буквенные обозначения в номере версии:

alpha — как правило, первая публичная тестовая версия, перед выходом финальной версии. Служит для обкатки и тестирования.

beta — вторая публичная тестовая версия, перед выходом финальной версии. Также служит для тестирования.

RC, RC2 — релиз-кандидат (Relise Candidate) версия, почти готовая к релизу. Служит для окончательной проверки.

final — окончательная (финальная) версия программы. Используется крайне редко, обычно просто опускается.

Какую схему наименования версий использовать решать прежде всего разработчикам, главное, чтобы нумерация была удобна в разработке и понятна конечному пользователю. И это один из тех вопросов, о которых необходимо договариваться в самом начале разработки любого проекта.

Major.Minor.Patch

An illustrated guide to semantic versioning

A program’s version does not represent the state of the software, but makes a statement about its API for the consumer.

Semantic versioning does not reflect the size of the update, but the changes in the software’s public API.

Introduction

As part of breaking up monolithic applications at Fiverr, we’re sharing a lot of functionality between programs using various strategies to create independent, interchangeable pieces of software; Ruby Gems, Node Packages, Godeps, and so on. We will address them all as “modules” from here on.

Loose dependencies of software, matching to highest patch (

) or even highest minor ( ^ ), is very common, and spawning new images in different times could result in different version of modules on different machines. This is desired behaviour. We want the ability to run latest versions of modules with the latest performance improvements and vulnerability fixes, without the need to manually update the code.

Where applicable, we use semantic versioning to manage this. It is important to follow the rules of versioning to avoid breakage. Bad versioning can cause unexpected behaviour, from different bundle outputs causing different fingerprints across servers, to operations straight up breaking in a project we didn’t update. These instances can be the hardest to locate and debug, because they do not involve direct code change.

Enter Joe

Joe’s gonna help us illustrate the purpose of versioning.

This is where we meet Joe, in Joe’s first major release. Joe is a software with internal logic and an API, making his functionality available to his consumers (He can walk, talk, and throw a fist).

Patch

Patch updates are interchangeable, meaning consumers can upgrade or downgrade freely.

Content: Internal fix
Example: Bug fix, Performance improvement, environment or internal tweaks
Policy: Consumers should update their software without hesitation

We thought Joe’s a bit too slow on his feet. Research suggests sandals can really help Joe pick up the pace. This is an internal update, it does not change any of Joe’s behaviour or abilities, but improves on existing ones. We’ll update a patch so our consumers know they should update.

Minor

Minor updates are backward compatible, meaning consumers can upgrade freely.

Content: Interface change with full backward compatibility
Example: New feature, Endpoint declared deprecated
Policy: Update your software to get some new features. Nothing will break

As we go along adventuring with Joe, we decide to add some functionality to Joe’s interface. We’ve added some weaponry. Now Joe’s able to fight more fiercely and tackle more challenging endeavours.

Since we’ve added to Joe’s interface, we’re upgrading a minor version. Joe can do everything he used to, and then some!

We’re continuing to upgrade Joe with new features, but our tests suggest Joe could perform better using an axe instead of his sword. Because we want Joe’s users to keep updating without fear of old functionality breaking, we’ve decided to give him a small axe with which he can still jab, but we’re recommending users to start swinging, instead. This is called a deprecation strategy.

Major

Major updates are non-compatible, meaning consumers can not upgrade without changing their software where applicable.

Content: Interface change breaking backward compatibility
Example: Change API endpoint name or signature, Remove an endpoint
Policy: Test your system extensively post update.
Migration documents may be in order

Finally, we decide it’s time to move on to Joe’s big boy’s axe. To do that we need to free up Joe’s other hand, which means he can’t use his shield any more. We’ve removed some of Joe’s functionality, which means this version is not fully backward compatible. It means users relying on Joe’s behaviour should update carefully, and replace instances where they’re on his shield if there are any. Their programs might break if they don’t test their usage. And while we’re breaking compatibility, we’re going to drop support of Jab, too.

Patch

It has come to our attention, that a Joe has a vulnerability caused by his feather. It makes him too visible on the battle field and we’ve decided to remove it.
Because this is a patch, our users know they can safely upgrade without rigorously testing their programs.

But the feather wasn’t introduced in this major release, it was introduced in an older version. If we want to keep supporting our user base, we should release a patch to our old versions as well.

This is where tagging comes in. You may have noticed, we’ve also published tags (named versions of our software), along the way and used our release numbers as tag names. Now we can easily go back and release a fix, then increment a patch on the old version.

Extensions

Pre-Release

Alpha (or Beta, etc.) versions are considered unstable, and do not abide versioning restrictions.

Release candidate means this version is under consideration for release.

Build Number

Builds are usually internal software releases of working versions of the code.
It is considered that build differ in build metadata only. They usually accept either timestamp or subsequent numbers as a name. The convention is to append them using a plus sign:

Build versions do not have any precedence one over the other.

When *not* to update

Occasionally, a maintainer or contributor only suggests readability or documentation fixes. Renaming a private variable or method; Adding or fixing documentation and code examples or some convention technicalities.

Since these changes are only meant for other maintainers, or to instruct how to better use the program, they do not affect the program’s operations and should not trigger a version update (not including build number extension of course).

Exceptions

Public API should not be considered stable under version 1.0.0

Major version minor version windows

Question

I need the following information for Windows 10 Preview:

Answers

Open Powershell and type: [System.Environment]::OSVersion.Version

• Proposed as answer by John Marlin [MSFT] Microsoft employee Wednesday, October 8, 2014 10:32 PM
• Marked as answer by Cloud_TS Moderator Tuesday, October 21, 2014 1:33 PM

Please see if the following information would meet your needs :

Michael Shao
TechNet Community Support

• Marked as answer by Cloud_TS Moderator Tuesday, October 21, 2014 1:33 PM

All replies

Open Powershell and type: [System.Environment]::OSVersion.Version

• Proposed as answer by John Marlin [MSFT] Microsoft employee Wednesday, October 8, 2014 10:32 PM
• Marked as answer by Cloud_TS Moderator Tuesday, October 21, 2014 1:33 PM

Please see if the following information would meet your needs :

Michael Shao
TechNet Community Support

• Marked as answer by Cloud_TS Moderator Tuesday, October 21, 2014 1:33 PM

One thing to remember is that GetVersionEx (and all of its variants including the OS object under Environment in .Net) now lies and will return 6.2 (Windows 8.0) when queried unless a specific app compat shim is in force for the application querying it. See this MSDN article about it:

See right at the top where it says it is «altered» for Windows 8.1 and later. Where this can hurt (at least where it hurts us) is if you have a script that installs, for example, an update to IE 11 and it needs to know if it should run the version of the MSU file for IE11 on Win7, IE 11 on Win 8, IE 11 on Win 8.1, etc. It will see Win 8, Win 8.1, and Win 10 as THE SAME when the script retrieves the version in code. So you end up having to fiddle with things like running ver.exe and examining the output from your script.

For real code, you can use the version helper API (referenced in the link above as well) to cobble together some code that will get you the real version info.