The Code build number or Trainz build version (two names meaning the identical 'tracking number') is a type of model number of the software, an unique software specific identifier that in Trainz practices— increments not only with 'named' main retail releases, but with each release for specific language groups, and by Hotfixes, as well as by Service_pack releases. As described in the Notes section below, it also changes in-house with software under development[note 1]
Initial Trainz code build versions are not released in initial retail release versions for all world wide languages at the same time, but these are produced as available translations, so typically, non-English releases lag by some months, but may have hot fixes or service packs already installed. As the translation needs are satisfied and an overall release stabilizes, subsequent service pack releases apply to those code build numbers and effectively combine language releases into a merged common product. At the end of the process, the final service pack produces a single stable code build version, creating the final corresponding Trainz (two digit) version number and corresponding identical Trainz-build tag level found in assets config.txt file.
Trainz versions are known best by their 'Retail Release name', after which N3V Games/Auran, following general software industry practices subsequently release bug fixing hot fixes and usually a succession of service packs. The below table is for the most recent Windows release.
For detailed code build version increments in various versions, Click to see table:
The term 'build' or 'build code' or 'code build' is a computing industries term of art, and is in fact a software serial number identifying a unique combination of software component files, 'built' or 'made' into a particular software package of resultant files. It derives directly from 'making' a 'build' with a script asset generally known as a 'make file' which lists out component parts, instructions on how they are to be processed into intermediate binary files (with specific names) and in what order, and additional instructions on linking the binary object files into specific modules. Make files also have the capability of tracking dependencies and if a component file changes, re-building the dependent software module. IDE's or Integrated Development Environments may layer another interface above the Make level, but in effect, those merely auto-edit the make scripts, then execute the build or make. The IDE thus provides data management automation relieving some of the responsibility of updating the make or build specification from the developers.
The make or build can be partial or all up, so that the 'full' make process generates a suite of finished Library assets, executables, and dynamic link libraries whose integration can then be tested and evaluated for further development, or adjudged as 'finalized' and stable, at all times then ready for a supporting role in testing related dependent code which may not be so ready. The partial make can rebuild only a part of the software, which has had further development and changes. The auto-dependency sensing of source file changes, protects the developers from forgetting a change by another member of the team; ensuring all the coder are on the same page evaluating the same build and symptoms.
A 'final build' might also specify copying such retail release boilerplate support files (e.g. keyboard hotkeys mapping files, initial user specific files) into a single installation—the build, which is released to publication.
On the release of a version for Q&A testing or publication for retail release, the build might then be compressed and distributed, so the end user Installs them, which mostly involves a bit of bookkeeping in the computer's registry and uncompressing the ready to use files from the DVD or internet source. In the later case, the local installer's generally consist of a FTP download manager combined with the file extraction (uncompressing) software.
Obviously, in modularize software such as Trainz, software update builds would only need to replace run-time software and libraries which have been updated since the last stable 'base' version. Some require processing local data and perhaps incorporate a patching or translation stage for certain assets, such as defaulting a problematic kind engine parameter if and when a ..\local (from 3rd party or the DLS sources) asset or JA asset hadn't defined the data. Such a stage often incurs an extremely long processing cycle of many hours such as several that occurred in several Service Packs during TS2009 and TS2010's evolution.
Config.txt files are endemic and ever present in Trainz assets, for no asset can be defined without this type of Computer Science container. The keyword-value_of_key pairing must always be kept in mind in editing or creating Trainz content. The TrainzBaseSpec contains values and containers which are most common in asset defining config.txt files.
↑In a December 2013 email, Trainz Version Manager James Moody stated that at times he did as many as five or six builds and related Trainz Installs a day.
↑Sequence confirmed by Author ed. Fabartus with successive careful installs of TS10, keeping different versions on different drives as installed to new computer. Hotfix from build 43434 inferred from patching method. Manual patch directly skipped.
↑ abInvalid <ref> tag; no text was provided for refs named Scottbe8
↑Trainz TS10 and TS12 Hot-fix Patches released,Later annotated: "Note: To be able to install Aerotrain and any future DLC packs, you will need to install this patch for your Trainz build.", Last edited by shadowarrior; November 17th, 2011 at 08:27 PM.