Today we’re announcing the release of NGINX 1.6 and 1.7. This article explains how we schedule product releases at NGINX, Inc., and explains the significance of this version number change.
NGINX 1.6 was forked from the current mainline branch (1.5), which was then renumbered to 1.7. This is an annual checkpoint where we take the current mainline (feature) branch and fork it to a stable (no new features) branch. We continue active development on the renumbered mainline branch.
In NGINX nomenclature, “stable” means that no new features are added (the feature set is stable). Only major bug fixes are committed to that version.
We develop new features and all bug fixes in the mainline branch. We operate a time-based release process, so you can expect to see new mainline releases approximately once per month, with exceptional releases when necessary. Over the last year, the mainline has seen the introduction of SPDY 3.1 support, authentication via subrequests, SSL session ticket support, IPv6 support for DNS, and PROXY protocol support. We integrated community contributions for SSL support for uwsgi. We’ve extended error logging, added cache revalidation directives, added SMTP pipelining, added buffering options for FastCGI, improved support for MP4 streaming, and extended handling of byte-range requests for streaming and caching.
Note that stable does not mean more reliable or more bug-free. In fact, the mainline is generally regarded as more reliable because we port all bug fixes to it, and not just critical fixes as for the stable branch. On the other hand, changes in the stable branch are very unlikely to affect third-party modules. We don’t make the same commitment concerning the mainline, where new features can affect the operation of third-party modules.
Which Version Should I Use?
We recommend that in general you deploy the NGINX mainline branch at all times. The main reason to use the stable branch is that you are concerned about possible impacts of new features, such as incompatibility with third-party modules or the inadvertent introduction of bugs in new features.
If you install NGINX from a third-party repository, you might not have control over which version is deployed, and the repository might not keep pace with the mainline and stable branches. Where possible, install NGINX from our repository, where the binaries are tested against our internal regression framework and keep pace with releases from the official NGINX source.
You can run the
-V command to determine the version number of your NGINX binary:
user@host:~$ nginx -V nginx version: nginx/1.5.12
What About NGINX Plus?
NGINX Plus is the commercially-supported version of NGINX, with a number of additional features, many of which utilize a new shared-memory architecture specific to NGINX Plus). NGINX Plus tracks the mainline version of NGINX, and is typically released on a three-month cycle. New features in the mainline branch are merged into NGINX Plus and released once they have passed full integration testing and have been proven in field deployments of NGINX:
The internal version numbers in NGINX Plus match the mainline release with which NGINX Plus is most closely synchronized.