This wiki is archived and useful information is being migrated to the main bzflag.org website

Difference between revisions of "Versions"

From BZFlagWiki
Jump to: navigation, search
m (fixed accidental repetition)
(Released versions of BZFlag: update)
 
(14 intermediate revisions by 5 users not shown)
Line 1: Line 1:
BZFlag has undergone several different numbering schemes over the years (decades) that can be roughly categorized as follows:  the 1.7 alphabet soup series, the 1.10 through 2.0 series, and the "new" triplet system currently in place.  The information in follwoing regarding BZFlag's versioning scheme pertains to the "new" triplet system currently in use.
+
==Version Numbering Systems==
+
===History===
Ever since the unreleased 1.9 development revision, BZFlag has been using a '''MAJOR.MINOR.PATCH''' version numbering scheme that is familiar to many open source software projects.  In this triplet version numbering scheme, the '''MAJOR''' number implies predominant backwards software compatibility; the '''MINOR''' number represents feature additions and enhancements; and the '''PATCH''' number is iterated releases of that given '''MAJOR.MINOR''' version.  Each number in that triplet is independent and is not necessarily just a single digit for each either (e.g., 2.10 is ''not'' the same as 2.1.0 nor 2.0.10).  For brevity, releases since 2.0 can generally be referred to only using the '''MAJOR.MINOR''' revision, leaving the '''PATCH''' version number off.
+
BZFlag has undergone several different numbering schemes over the years (decades) that can be roughly categorized as follows:  the 1.7 alphabet soup series, the 1.10 through 2.0 series, and the "new" "quad" system currently in place.  The information in following regarding BZFlag's version scheme pertains to the system put into place for the v2.3 /2.4 release
  
In order to "encourage" upgrades and facilitate making enhancements and bug fixes to the game, BZFlag's developers (intentionally) break the game protocol from time to time where new clients are released that will not work with previous releases.  Starting with BZFlag version 2.0, the '''MAJOR''' number in BZFlag's versioning triplet '''''represents backwards-compatibility'''''.  That is to say that all clients with a version number starting with a 2 will (only) work with others of that 2 series.
+
===Current System===
 +
The version system uses a 4 digit system that contains the following values
  
''Development of a new '''MAJOR''' version of BZFlag occurs as the previous '''MAJOR''' version number's '''99th''' '''MINOR''' revision. (e.g., 2.99 becomes 3.0, 3.99 becomes 4.0)'' The '''99th''' development revision is necessarily treated special and generally not compatible with anything but itself.
+
'''MAJOR''' . '''MINOR''' . '''RELEASE''' . '''BUILD'''
  
As compatible releases and enhancements are made to the game, they are released with an ''even-numbered'' '''MINOR''' version number (e.g. 3.'''0''' or 2.'''2''' or 3.'''2'''.6 etc).  Versions of the game with an ''odd-numbered'' '''MINOR''' version number represents development-only versions that should not be used by non-developers under any circumstances ''(i.e., you're on your own, no support or guarantees are offered)''.  Again, revisions with an '''''odd''''' second number represent '''''developer revisions''''' and those with an '''''even''''' second number are the '''''public revisions'''''.
+
This numbering scheme is similar to many open source software projects.  
  
The '''PATCH''' number in the version triplet counts publicly posted revisions for a given '''MAJOR.MINOR''' version.  Since the BZFlag developers do intentionally provide (pre-release, alpha, beta) versions the game before a ''final'' post is made, those releases merely have the '''PATCH''' number incremented.  Basically, the '''PATCH''' number can be looked at as how many times files have been publicly posted for a given '''MAJOR.MINOR''' version.
+
In this version numbering scheme, the '''MAJOR''' number implies predominant changes to the software system that makes it visually different from the previous version.  
  
Labels and comments that a given release is an ''RC'' (Release Candidate) version or that it's a ''beta'' or an ''alpha'' release are merely inteded to describe the stability of a given version but are '''not''' part of the version itself.  Lower patch numbers on a developer revision (where the '''MINOR''' number is an ''odd-number'') tend to imply less stability whereas higher patch numbers tend to imply greater stability.  On non-developer releases, the number is generally only incremented and reposted if there was something deficient with the version already posted.
+
The '''MINOR''' number represents changes to a version that break it's compatibility with with previous releases.
  
== Revision number examples ==
+
The '''RELEASE''' number is iterated across the various releases of that given '''MAJOR.MINOR''' version and represents feature additions and enhancements that maintain compatability with all versions sharing the same '''MAJOR.MINOR''' pair.
  
2.99.0 is a developer revision that will become the next 3.0 major release.  Only developers should be using this revision.
+
The '''BUILD''' number is incremented each time a package is built and posted. It is updated often and represents only minor changes to the code or packaging system. This is what we change to differentiate different downloads of the same code.
  
2.99.27 is the 28th developer revision of 2.99, perhaps approaching some sort of beta or release-candidate status for the 3.0 release. Only developers and testers should be using this revision.
+
===Development Versions and Release Versions===
 +
Development of a new version of BZFlag occurs on the odd version of the lowest required version number. Incompatable releases use an odd '''MINOR''' version. A special case is held for development of a new '''MAJOR''' version, it is done using the '''MINOR''' version of 99.
  
3.0.0 is a new release of a BZFlag client that is incompatible with all previous versions. This revision is for everyone.
+
Releases are always done with even numbers in the first triplet. The build number is simply increment for each publishing.
  
3.0.9 is the 10th release of the 3.0 client, only providing minor bug and build fixes.  This revision is for everyone.
+
====Examples====
 +
2.3.x.x is development for 2.4.0.0
  
3.1.0 is a developer revision of the 3 series, compatible with other version 3 clients and a pre-release candidate for the 3.2 release. Only developers should be using this revision.
+
2.4.0.1 and 2.4.0.2 are both builds of a 2.4.0 release.
  
3.12.4 is the 5th patch update of the 3.12 public release intended for everyone.  There were six compatible versions released prior to this version: 3.0, 3.2, 3.4, 3.6, 3.8, and 3.10 
+
2.4.1.x is development for 2.4.2.0
  
3.2.5 is the 6th publicly posted release of version 3.2, serving enhanced functionality over the previous 3.0 clients while remaining compatible with other 3 series clients.  This revision is for everyone.
+
2.99.x.x is development for 3.0.0.0
  
3.99.0 is a developer revision that will become the next 4.0 major releaseOnly developers should be using this revision
+
 
 +
===Release Candidates===
 +
Labels and comments that a given release is an ''RC'' (Release Candidate) version or that it's a ''beta'' or an ''alpha'' release are merely intended to describe the stability of a given version but are '''not''' part of the version itself.  Lower patch numbers on a developer revision (where the '''MINOR''' number is an ''odd-number'') tend to imply less stability whereas higher patch numbers tend to imply greater stability. On non-developer releases, the number is generally only incremented and reposed if there was something deficient with the version already posted.   
  
 
== Released versions of BZFlag ==
 
== Released versions of BZFlag ==
There are currently 34 open source versions of BZFlag. Versions earlier then 1.7c-X were closed source.
+
There are currently 40 open source versions of BZFlag. Versions earlier then 1.7c-X were closed source.
 +
 
 +
The versions in chronological order are:
 +
 
 +
{|{{Prettytable}}
 +
|-
 +
| {{Hl3}} |'''BZFlag Releases'''
 +
|-
 +
| [[BZFlag 1.7c-1]]
 +
|-
 +
| [[BZFlag 1.7c-2]]
 +
|-
 +
| [[BZFlag 1.7c-2-1]]
 +
|-
 +
| [[BZFlag 1.7c-2-2]]
 +
|-
 +
| [[BZFlag 1.7c-2-3]]
 +
|-
 +
| [[BZFlag 1.7d-1]]
 +
|-
 +
| [[BZFlag 1.7d-2]]
 +
|-
 +
| [[BZFlag 1.7d-3]]
 +
|-
 +
| [[BZFlag 1.7d-4]]
 +
|-
 +
| [[BZFlag 1.7d-5]]
 +
|-
 +
| [[BZFlag 1.7d-6]]
 +
|-
 +
| [[BZFlag 1.7d-7]]
 +
|-
 +
| [[BZFlag 1.7d-8]]
 +
|-
 +
| [[BZFlag 1.7d-9]]
 +
|-
 +
| [[BZFlag 1.7e]]
 +
|-
 +
| [[BZFlag 1.7e1]]
 +
|-
 +
| [[BZFlag 1.7e2]]
 +
|-
 +
| [[BZFlag 1.7e4]]
 +
|-
 +
| [[BZFlag 1.7e6]]
 +
|-
 +
| [[BZFlag 1.7g0]]
 +
|-
 +
| [[BZFlag 1.7g2]]
 +
|-
 +
| [[BZFlag 1.10.0]]
 +
|-
 +
| [[BZFlag 1.10.2]]
 +
|-
 +
| [[BZFlag 1.10.4]]
 +
|-
 +
| [[BZFlag 1.10.6]]
 +
|-
 +
| [[BZFlag 1.10.8]]
 +
|-
 +
| [[BZFlag 2.0.0]]
 +
|-
 +
| [[BZFlag 2.0.2]]
 +
|-
 +
| [[BZFlag 2.0.4]]
 +
|-
 +
| [[BZFlag 2.0.6]]
 +
|-
 +
| [[BZFlag 2.0.8]]
 +
|-
 +
| [[BZFlag 2.0.10]]
 +
|-
 +
| [[BZFlag 2.0.12]]
 +
|-
 +
| [[BZFlag 2.0.14]]
 +
|-
 +
| [[BZFlag 2.0.16]]
 +
|-
 +
| [[BZFlag 2.4.0]]
 +
|-
 +
| [[BZFlag 2.4.2]]
 +
|-
 +
| [[BZFlag 2.4.4]]
 +
|-
 +
| [[BZFlag 2.4.6]]
 +
|-
 +
| [[BZFlag 2.4.8]]
 +
|-
 +
| [[BZFlag 2.4.10]]
 +
|-
 +
|}
 +
 
 +
== Development versions of BZFlag ==
 +
Every release is preceded by a development version. These versions are where the developers work on the code that goes into each release. Development versions for major releases are generally not compatible with any other release, including different builds of themselves.
  
The versions in chronological order are;
+
Some of these development releases had there own pages for development planning. This is a list of them for historical reference.
  
* [[BZFlag 1.7c-1]]
 
* [[BZFlag 1.7c-2]]
 
* [[BZFlag 1.7c-2-1]]
 
* [[BZFlag 1.7c-2-2]]
 
* [[BZFlag 1.7c-2-3]]
 
* [[BZFlag 1.7d-1]]
 
* [[BZFlag 1.7d-2]]
 
* [[BZFlag 1.7d-3]]
 
* [[BZFlag 1.7d-4]]
 
* [[BZFlag 1.7d-5]]
 
* [[BZFlag 1.7d-6]]
 
* [[BZFlag 1.7d-7]]
 
* [[BZFlag 1.7d-8]]
 
* [[BZFlag 1.7d-9]]
 
* [[BZFlag 1.7e]]
 
* [[BZFlag 1.7e1]]
 
* [[BZFlag 1.7e2]]
 
* [[BZFlag 1.7e4]]
 
* [[BZFlag 1.7e6]]
 
* [[BZFlag 1.7g0]]
 
* [[BZFlag 1.7g2]]
 
* [[BZFlag 1.10.0]]
 
* [[BZFlag 1.10.2]]
 
* [[BZFlag 1.10.4]]
 
* [[BZFlag 1.10.6]]
 
* [[BZFlag 1.10.8]]
 
* [[BZFlag 2.0.0]]
 
* [[BZFlag 2.0.2]]
 
* [[BZFlag 2.0.4]]
 
* [[BZFlag 2.0.6]]
 
* [[BZFlag 2.0.8]]
 
 
* [[BZFlag 2.0.9]]
 
* [[BZFlag 2.0.9]]
* [[BZFlag 2.0.10]]
+
* [[BZFlag 2.99]]
* [[BZFlag 2.2]]
+
* [[BZFlag 2.3]]
 
* [[BZFlag SVN]]
 
* [[BZFlag SVN]]
  
 
[[Category:History]]
 
[[Category:History]]

Latest revision as of 18:22, 12 March 2017

Version Numbering Systems[edit]

History[edit]

BZFlag has undergone several different numbering schemes over the years (decades) that can be roughly categorized as follows: the 1.7 alphabet soup series, the 1.10 through 2.0 series, and the "new" "quad" system currently in place. The information in following regarding BZFlag's version scheme pertains to the system put into place for the v2.3 /2.4 release

Current System[edit]

The version system uses a 4 digit system that contains the following values

MAJOR . MINOR . RELEASE . BUILD

This numbering scheme is similar to many open source software projects.

In this version numbering scheme, the MAJOR number implies predominant changes to the software system that makes it visually different from the previous version.

The MINOR number represents changes to a version that break it's compatibility with with previous releases.

The RELEASE number is iterated across the various releases of that given MAJOR.MINOR version and represents feature additions and enhancements that maintain compatability with all versions sharing the same MAJOR.MINOR pair.

The BUILD number is incremented each time a package is built and posted. It is updated often and represents only minor changes to the code or packaging system. This is what we change to differentiate different downloads of the same code.

Development Versions and Release Versions[edit]

Development of a new version of BZFlag occurs on the odd version of the lowest required version number. Incompatable releases use an odd MINOR version. A special case is held for development of a new MAJOR version, it is done using the MINOR version of 99.

Releases are always done with even numbers in the first triplet. The build number is simply increment for each publishing.

Examples[edit]

2.3.x.x is development for 2.4.0.0

2.4.0.1 and 2.4.0.2 are both builds of a 2.4.0 release.

2.4.1.x is development for 2.4.2.0

2.99.x.x is development for 3.0.0.0


Release Candidates[edit]

Labels and comments that a given release is an RC (Release Candidate) version or that it's a beta or an alpha release are merely intended to describe the stability of a given version but are not part of the version itself. Lower patch numbers on a developer revision (where the MINOR number is an odd-number) tend to imply less stability whereas higher patch numbers tend to imply greater stability. On non-developer releases, the number is generally only incremented and reposed if there was something deficient with the version already posted.

Released versions of BZFlag[edit]

There are currently 40 open source versions of BZFlag. Versions earlier then 1.7c-X were closed source.

The versions in chronological order are:

BZFlag Releases
BZFlag 1.7c-1
BZFlag 1.7c-2
BZFlag 1.7c-2-1
BZFlag 1.7c-2-2
BZFlag 1.7c-2-3
BZFlag 1.7d-1
BZFlag 1.7d-2
BZFlag 1.7d-3
BZFlag 1.7d-4
BZFlag 1.7d-5
BZFlag 1.7d-6
BZFlag 1.7d-7
BZFlag 1.7d-8
BZFlag 1.7d-9
BZFlag 1.7e
BZFlag 1.7e1
BZFlag 1.7e2
BZFlag 1.7e4
BZFlag 1.7e6
BZFlag 1.7g0
BZFlag 1.7g2
BZFlag 1.10.0
BZFlag 1.10.2
BZFlag 1.10.4
BZFlag 1.10.6
BZFlag 1.10.8
BZFlag 2.0.0
BZFlag 2.0.2
BZFlag 2.0.4
BZFlag 2.0.6
BZFlag 2.0.8
BZFlag 2.0.10
BZFlag 2.0.12
BZFlag 2.0.14
BZFlag 2.0.16
BZFlag 2.4.0
BZFlag 2.4.2
BZFlag 2.4.4
BZFlag 2.4.6
BZFlag 2.4.8
BZFlag 2.4.10

Development versions of BZFlag[edit]

Every release is preceded by a development version. These versions are where the developers work on the code that goes into each release. Development versions for major releases are generally not compatible with any other release, including different builds of themselves.

Some of these development releases had there own pages for development planning. This is a list of them for historical reference.