question: version numbers. What constitutes a shift from 2.0 to 3.0, versus 2.1, 2.1.1, 2.18.456, etc?
comment: Lots of different projects have different versioning systems. However, my preferred one (and a fairly common one) is called [Semver]( URL_0 ). With semver, it's separated into Major.Minor.Patch, where Major versions are for incompatible API changes, minor versions are for backwards-compatible features, and patch versions are for backwards compatible bugfixes.
passages: Between the 1.0 and the 2.6.x series, the Linux kernel used odd minor version numbers to denote development releases and even minor version numbers to denote stable releases; see . For example, Linux 2.3 was a development family of the second major design of the Linux kernel, and Linux 2.4 was the stable release family that Linux 2.3 matured into. After the minor version number in the Linux kernel is the release number, in ascending order; for example, Linux 2.4.0 → Linux 2.4.22. Since the 2004 release of the 2.6 kernel, Linux no longer uses this system, and has a much shorter release cycle.
   These are ABI compatible within their version, so a 1.1.12p5 config will work mostly unchanged for 1.1.12p6.
  
  "Innovation" releases are specially marked versions based on the development branch that are for public testing.
  
  Checkmk keeps the interfaces stable during the lifetime of a "p" release, but they may change between new stable releases.
  
  For example, there are changes between 1.1.10pnum and 1.1.12p.x where users will have to adjust their configuration.
  
  The same applies from 1.1.12 to 1.2, since this is a new major release.
  
  Ver 1.5.0p16 is the latest version as of 31st May 2019.
  
  Section::::Uses.
   KOffice underwent a major transition as part of the release of KDE Software Compilation 4 ("SC4"). Coinciding with the work on SC4, the KOffice team prepared a major new release – KOffice 2.0 – which used the new KDE Platform 4 libraries. Although version 2.0 was released in 2009, the release was labeled as a “platform release” which was recommended only for testers and developers, rather than production use, since the release was missing key features and applications from the previous stable release series.
   The numbering change from 2.6.39 to 3.0, and from 3.19 to 4.0, involved no meaningful technical differentiation. The major version number was increased to avoid large minor numbers.
  
  Section::::Development.
  
  Section::::Development.:Developer community.
   Some systems use numerical versions less than 1 (such as 0.9), to suggest their approach toward a final "1.0" release. This is a common convention in open source software. However, if the pre-release version is for an existing software package (e.g. version 2.5), then an "a" or "alpha" may be appended to the version number. So the alpha version of the 2.5 release might be identified as 2.5a or 2.5.a. 
   In some cases, developers may decide to reset the major version number. This is sometimes used to denote a new development phase being released. For example, "Minecraft" Alpha ran from version 1.0.0 to 1.2.6, and when Beta was released, it reset the major version number, and ran from 1.0 to 1.8. Once the game was fully released, the major version number again reset to 1.0.
  
  Section::::Schemes.:Sequence-based identifiers.:Separating sequences.
   The same odd-even system is used by some other software with long release cycles, such as Node.js up to version 0.12.
  
  Section::::Modifications to the numeric system.:Apple.
   Qt 5.0 was released 19 December 2012, Qt 5.2 12 December 2013. And for example KDE Frameworks 5.21.0 requires Qt = 5.4, and no longer supports Qt 5.3 (cf. Qt version history).
  
  Section::::Development.:Standard releases.
  
  There are two main types of standard releases: Feature releases and bugfix releases.
   In the mid-1990s, the rapidly growing CMMS, Maximo, moved from Maximo Series 3 directly to Series 5, skipping Series 4 due to that number's perceived marketing difficulties in the Chinese market, where the number 4 is associated with "death" (see tetraphobia). This did not, however, stop Maximo Series 5 version 4.0 being released. (It should be noted the "Series" versioning has since been dropped, effectively resetting version numbers after Series 5 version 1.0's release.)
  
  Section::::Significance in software engineering.
   The version number used in GIMP is expressed in a "major-minor-micro" format, with each number carrying a specific meaning: the first (major) number is incremented only for major developments (and is currently 2). The second (minor) number is incremented with each release of new features, with odd numbers reserved for in-progress development versions and even numbers assigned to stable releases; the third (micro) number is incremented before and after each release (resulting in even numbers for releases, and odd numbers for development snapshots) with any bug fixes subsequently applied and released for a stable version.
   Until 2016, eric used a software versioning scheme with a three-sequence identifier, e.g. 5.0.1. The first sequence represents the major version number which is increased when there are significant jumps in functionality, the second sequence represents the minor number, which is incremented when only some features or significant fixes have been added, and the third sequence is the revision number, which is incremented when minor bugs are fixed or minor features have been added.
  
  From late 2016, the version numbers show the year and month of release, e.g. 16.11 for November 2016.
  
  Section::::Releases.:Release strategy.
   Section::::Critical reception.:Accolades.
   BULLET::::- 1996 ToolBook 5.0, 5.01
  
  BULLET::::- 1998 ToolBook 6.0, 6.1, 6.1a
  
  BULLET::::- 1998 ToolBook 6.5
  
  BULLET::::- 1999 ToolBook 7.0
  
  BULLET::::- 1999 ToolBook 7.1
  
  BULLET::::- 2000 ToolBook 7.2
  
  BULLET::::- 2000 ToolBook 8.0
  
  BULLET::::- 2001 ToolBook 8.1
  
  BULLET::::- 2002 ToolBook 8.5
  
  BULLET::::- 2003 ToolBook 8.6
  
  BULLET::::- 2004 ToolBook 2004 (aka 8.9)
  
  BULLET::::- 2004 ToolBook 2004 SP1
  
  BULLET::::- 2005 ToolBook 2004 SP2
  
  BULLET::::- 2005 ToolBook 2004 SP3
  
  BULLET::::- 2007 ToolBook 9.0
  
  BULLET::::- 2007 ToolBook 9.01
  
  BULLET::::- 2008 ToolBook 9.5
  
  BULLET::::- 2009 ToolBook 9.5 Service Pack 1
  
  BULLET::::- 2009 ToolBook 10.0
  
  BULLET::::- 2010 ToolBook 10.0 Patch 1
  
  BULLET::::- 2010 ToolBook 10.5
   It was superseded by Firefox 4, released the next year, although FF 3.6 had a prolonged period of use and version 4 had noted user interface changes. Firefox 3.6 is the last major version of an official Firefox release to run on PowerPC-based Macintoshes (see TenFourFox for a much-more-recent version of Firefox for PowerPC-based computers running Mac OS X). Soon after 4, much less weight was given to major version numbers, with 6 numbers used by September of that year (4, 5, 6, 7, 8, and 9) compared to 3 in nearly a decade of Firefox development (1, 2 and 3).
   With version 3.2, the project decided to move to time-based releases. New major releases, such as 3.3, 3.4, etc. will appear every 6 months. New features will only be added when a major release is done, point-releases will be only for bug fixes. Also, 3.2 marked a change of license from GPL2 to GPL3, with some parts released under LGPL3. The main technical change in version 3.2 was to autogenerate much of the DCE/RPC-code that used to be handcrafted. Version 3.2.0 was released on 1 July 2008. and its current release is 3.2.15 from 1 October 2009. The 3.2.x series officially reached end-of-life on 1 March 2010.
   The somewhat unusual version number "3.0.5a" was used for a minor release of KDE because of a lack of version numbers. Work on KDE 3.1 had already started and, up to that day, the release coordinator used version numbers such as 3.0.5, 3.0.6 internally in the main CVS repository to mark snapshots of the upcoming 3.1. Then after 3.0.3, a number of important and unexpected bug fixes (starting from 3.0.4) suddenly became necessary, leading to a conflict, because 3.0.5 was at this time already in use. More recent KDE release cycles have tagged pre-release snapshots with large revision numbers, such as 3.1.95, to avoid such conflicts.
   BULLET::::- Joomla 2.5 was released on January 24, 2012, six months after 1.7.0. This version is a long term support (LTS) release. Originally this release was to be 1.8.0, however the developers announced August 9 that they would rename it to fit into a new version number scheme in which every LTS release is an X.5 release. This version was the first to run on other databases besides MySQL. Support for this version was extended until the end of 2014.
   openSUSE 12.2 was to be released on July 11, 2012, but was postponed due to persistent stability issues. The final release candidate was eventually announced on August 2, 2012 and the final release date was September 5, 2012. 12.2 includes the desktop environments Plasma 4.8, GNOME 3.4, Firefox 14.0.1, and Xfce 4.10 and now uses Plymouth and GRUB 2 by default.
   The jump in version numbers from Darwin 1.4.1 to 5.1 with the release of Mac OS X v10.1.1 was designed to tie Darwin to the Mac OS X version and build numbering system, which in turn is inherited from NeXTSTEP. In the build numbering system of macOS, every version has a unique beginning build number, which identifies what whole version of macOS it is part of. Mac OS X v10.0 had build numbers starting with 4, 10.1 had build numbers starting with 5, and so forth (earlier build numbers represented developer releases).
   A different approach is to use the "major" and "minor" numbers, along with an alphanumeric string denoting the release type, e.g. "alpha" (a), "beta" (b), or "release candidate" (rc). A software release train using this approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (with some fixes), 1.0b3 (with more fixes) → 1.0rc1 (which, if it is stable "enough"), 1.0rc2 (if more bugs are found) → 1.0. It is a common practice in this scheme to lock-out new features and breaking changes during the release candidate phases and for some teams, even betas are lock-down to bug fixes only, in order to ensure convergence on the target release.
   Reginald Stadlbauer began development of KPresenter in 1997. The first official release of the KOffice suite was on October 23, 2000 when it was released as part of K Desktop Environment 2.0. Versions 1.1 followed in 2001, 1.2 in 2002, 1.3 in 2004, 1.4 in 2005, and 1.5 and 1.6 both in 2006.
   From 2004 until 2007 OpenOffice Polska made commercial Kexi releases using release years as version numbers. The first release was "Kexi 2004 LT" on based on Kexi 0.1. The commercial releases concluded with "Kexi 2007.1" in March 2007 based on Kexi 1.1.2/1.1.3.
   Software may have an "internal" version number which differs from the version number shown in the product name (and which typically follows version numbering rules more consistently). Java SE 5.0, for example, has the internal version number of 1.5.0, and versions of Windows from NT 4 on have continued the standard numerical versions internally: Windows 2000 is NT 5.0, XP is Windows NT 5.1, Windows Server 2003 and Windows XP Professional x64 Edition are NT 5.2, Windows Server 2008 and Vista are NT 6.0, Windows Server 2008 R2 and Windows 7 are NT 6.1, Windows Server 2012 and Windows 8 are NT 6.2, and Windows Server 2012 R2 and Windows 8.1 are NT 6.3, however the first version of Windows 10 was 10.0 (10.0.10240). Note, however, that Windows NT is only on its fifth major revision, as its first release was numbered 3.1 (to match the then-current Windows release number) and the Windows 10 launching made a version leap from 6.3 to 10.0.
   Some projects use negative version numbers. One example is the SmartEiffel compiler which started from -1.0 and counted upwards to 0.0.
  
  Section::::Schemes.:Date of release.
  
  The Wine project formerly used a date versioning scheme, which uses the year followed by the month followed by the day of the release; for example, "Wine 20040505". Ubuntu Linux uses a similar versioning scheme—Ubuntu 11.10, for example, was released October 2011. Some video games also use date as versioning, for example the arcade game Street Fighter EX. At startup it displays the version number as a date plus a region code, for example "961219 ASIA".
   Beyond the technical improvements, the 1.x series is also defined by a new release versioning scheme. As the GStreamer roadmap explains, all 1.x.y versions carry a -1.0 API version suffix and have a stable API/ABI. The API/ABI can only be broken by a new major release series (i.e.: 2.x); however, there are currently no plans for a 2.0 release series. Until then, the new version numbering scheme can be used to predict the intended use of each release. The roadmap cites some examples:
  
  BULLET::::- 1.0.0, 1.0.1, 1.0.2, 1.0.3... stable release and follow-up bug-fix releases
  