Difference between revisions of "Version numbering"

From Second Life Wiki
Jump to navigation Jump to search
m (updated SL History Wiki URL to reflect migration to wikia.com)
Line 2: Line 2:




==What do the numbers in a release version mean?==  
== What do the numbers in a release version mean? ==  
* 1.x.y.z? And why is it sometimes 1.x.y(z)?
* 1.x.y.z? And why is it sometimes 1.x.y(z)?
* For example, '''version 1.21.6(99587)'''
* For example, '''version 1.21.6(99587)'''




These version numbers follow a common convention in software engineering of four numbers. The common definition of w.x.y.z-style release numbers is Major.Minor.Patch.Revision.   
These version numbers follow a four place version convention common to the software industry. The four places of w.x.y.z-style release numbers are typically described as Major.Minor.Patch.Revision.   




'''w (Major)'''<br/>
'''w (Major)'''<br/>
Using that terminology, Second Life has only had one Major version change - from 0.x beta to 1.0 release. As Second Life is a constantly evolving service and platform rather than a traditional monolithic software application, we have no current plans to increment the initial number.
The first place in each version number represents the "generation" of Second Life.  Changes in the Major revision are reserved for comprehensive changes in the way Second Life looks and/or functions.  The best example is Viewer 2, which represents a significant change in the look, feel and operation of Second Life - justifying the increment from 1.23 to 2.0.





Revision as of 09:18, 4 November 2010


What do the numbers in a release version mean?

  • 1.x.y.z? And why is it sometimes 1.x.y(z)?
  • For example, version 1.21.6(99587)


These version numbers follow a four place version convention common to the software industry. The four places of w.x.y.z-style release numbers are typically described as Major.Minor.Patch.Revision.


w (Major)
The first place in each version number represents the "generation" of Second Life. Changes in the Major revision are reserved for comprehensive changes in the way Second Life looks and/or functions. The best example is Viewer 2, which represents a significant change in the look, feel and operation of Second Life - justifying the increment from 1.23 to 2.0.


.x (Minor) and .y (Patch)

  • Linden Lab uses the second digit x to denote a substantial new feature or sizable release, for example:
    • 1.10 introduced flexi prims
    • 1.11 was a revamp of the UI layer
    • 1.12 had groups and estates improvements
    • 1.14 introduced render pipeline improvements
    • 1.20 introduced a "Silver" skin for the user interface
    • 1.21 introduced the ability to save scripts with the Mono scripting engine
    • 1.22 was a maintenance release with many bug fixes
    • and so on.
    • (The SL History Wiki http://secondlife.wikia.com/index.php/Release_Notes has unofficial archives of the release notes.)


  • In between these Minor 1.x versions are any improved builds (small iterations of little bug fixes) denoted by the third digit .y.
    • Most often, while a Minor 1.x version is in its beta or Release Candidate RC status, it will undergo 3-6 such build iterations. Thus it will typically become "official" with a number like 1.20.6.
    • EXCEPTION: In the versions from 1.15 to 1.19, Linden Lab switched to having the second digit (e.g. 1.19) denote a new viewer which was a mandatory upgrade for Residents, to go along with a server-side upgrade. Thus, from version 1.15 to 1.19, the in-between 1.x.y versions were any optional upgrades denoted by the third digit, y -- even those with substantial new features -- such as 1.19.1 introduced WindLight atmospheric rendering.


.z (Revision)
The final digit always represents a unique Revision number, which denotes internal changes only. The official released version of the Second Life viewer will only use the first three digits to have meaning (e.g. 1.20.6).

  • Some parts of the Second Life UI and Web site show this last digit in parenthesis (z) to emphasize the, er, parenthetical nature of that field - it shouldn’t be important except to software developers seeking a precise snapshot of when the code was packaged.