Release NGINX 1.6 and 1.7. Versioning Features
Yesterday, April 24, the release of NGINX 1.6 and 1.7 was announced. This article explains how NGINX releases are planned and the meaning of this version numbering change.
NGINX 1.6 is separated from the current main (mainline) branch 1.5, and the latter was renumbered in 1.7. This is an annual event when the current main branch is taken with a new functionality and a new stable branch is branched off from it. Development is actively continuing on the already renumbered main branch.
Version 1.4 is no longer supported. The main 1.5 branch was forked to create a stable 1.6 and renumbered at 1.7.
In NGINX terminology, “stable” means that new features will not be added. In other words, the set of functions remains stable and only fixes for serious bugs fall into these versions.
')
The development of new features and the correction of all the bugs occurs on the main branch, but critical bugfixes thus fall into a stable branch. The release process is time-bound, so you can expect regular releases in the main branch about once a month, with exceptions when necessary. Over the past year, support for SPDY 3.1 , authentication using subqueries , TLS session tickets , IPv6 support in a DNS resolver , PROXY protocol support , and support for SSL connections for the uwsgi protocol have been added to the main branch. In addition, error logging capabilities have been expanded, cache revalidation has been added, SMTP pipelining support, new buffering options for FastCGI , streaming support for mp4 , as well as processing byte-range requests for streaming and caching.
It is worth noting that “stable” does not mean greater reliability and fewer bugs. In fact, the main branch is considered to be more reliable, since only critical fixes fall into a stable branch. Changes in the stable branch should not affect third-party modules, which is not the case with the main branch, where the new functionality may affect the performance of third-party code.
It is recommended to use the main NGINX branch all the time. But you can use stable if you are concerned about possible problems from innovations, such as incompatibility with third-party modules or bugs in the new functionality.
If you have connected the official NGINX repository (stable or main branch), then the next update will load the latest 1.6 or 1.7 build, respectively.
If you installed NGINX from a third-party repository, then you (probably) have no control over which version will be deployed, and the repository may not keep up with the release of new versions in one of the branches. If possible, it is recommended to install NGINX from the official repository (on nginx.org), where all assemblies pass internal regression tests and are updated with the release of new versions from the official source.
You can run
NGINX Plus is a commercially supported version of NGINX with advanced features (many of which use the new shared-memory architecture specific to the Plus version). NGINX Plus follows versions in the main NGINX branch and usually has a three-month release cycle. New functionality in the main branch is added to Plus, then released after the integration testing process and verification in combat in the NGINX F / OSS versions:
NGINX Plus is based on mainline versions and has extended functionality.
The internal numbering of NGINX Plus versions corresponds to the release in the main branch, with which NGINX Plus has been synchronized.
Official blog in English: nginx.com/blog
NGINX 1.6 is separated from the current main (mainline) branch 1.5, and the latter was renumbered in 1.7. This is an annual event when the current main branch is taken with a new functionality and a new stable branch is branched off from it. Development is actively continuing on the already renumbered main branch.
Version 1.4 is no longer supported. The main 1.5 branch was forked to create a stable 1.6 and renumbered at 1.7.
In NGINX terminology, “stable” means that new features will not be added. In other words, the set of functions remains stable and only fixes for serious bugs fall into these versions.
')
The development of new features and the correction of all the bugs occurs on the main branch, but critical bugfixes thus fall into a stable branch. The release process is time-bound, so you can expect regular releases in the main branch about once a month, with exceptions when necessary. Over the past year, support for SPDY 3.1 , authentication using subqueries , TLS session tickets , IPv6 support in a DNS resolver , PROXY protocol support , and support for SSL connections for the uwsgi protocol have been added to the main branch. In addition, error logging capabilities have been expanded, cache revalidation has been added, SMTP pipelining support, new buffering options for FastCGI , streaming support for mp4 , as well as processing byte-range requests for streaming and caching.
It is worth noting that “stable” does not mean greater reliability and fewer bugs. In fact, the main branch is considered to be more reliable, since only critical fixes fall into a stable branch. Changes in the stable branch should not affect third-party modules, which is not the case with the main branch, where the new functionality may affect the performance of third-party code.
So which version to choose?
It is recommended to use the main NGINX branch all the time. But you can use stable if you are concerned about possible problems from innovations, such as incompatibility with third-party modules or bugs in the new functionality.
If you have connected the official NGINX repository (stable or main branch), then the next update will load the latest 1.6 or 1.7 build, respectively.
If you installed NGINX from a third-party repository, then you (probably) have no control over which version will be deployed, and the repository may not keep up with the release of new versions in one of the branches. If possible, it is recommended to install NGINX from the official repository (on nginx.org), where all assemblies pass internal regression tests and are updated with the release of new versions from the official source.
You can run
nginx -V to find out the version number of your build: user@host:~$ nginx -v nginx version: nginx/1.5.12 And what about NGINX Plus?
NGINX Plus is a commercially supported version of NGINX with advanced features (many of which use the new shared-memory architecture specific to the Plus version). NGINX Plus follows versions in the main NGINX branch and usually has a three-month release cycle. New functionality in the main branch is added to Plus, then released after the integration testing process and verification in combat in the NGINX F / OSS versions:
NGINX Plus is based on mainline versions and has extended functionality.
The internal numbering of NGINX Plus versions corresponds to the release in the main branch, with which NGINX Plus has been synchronized.
Official blog in English: nginx.com/blog
Attention! Nginx Team is conducting a regular community survey to better define its development strategy. Do not miss the opportunity to express your opinion: mailman.nginx.org/pipermail/nginx/2014-April/043282.htmlUpd: Poll completed. Thanks to everyone who took part.
Source: https://habr.com/ru/post/220807/
All Articles