OpenTTD é um projeto em constante evolução, com novos recursos, opções, e melhorias se tornando disponíveis regularmente. Enquanto a adição freqüente de "novos brinquedos" para brincar é um benefício para os veteranos OpenTTD, pode ser um pouco confuso para o recém-chegado ao OTTD. Qual a versão que tem, o que eles devem instalar, e o que se esperar em termos de estabilidade de cada versão.
"Nightly?" "RC?" "Trunk?" O quê?
Compreender os termos que os desenvolvedores usam para se referir a diferentes "versões" de OpenTTD é a chave para obter os recursos (junto com a estabilidade) que você quer em seu jogo.
Uma "build" é um termo genérico que simplesmente se refere em particular a uma versão do jogo. As Builds podem ser oficiais, versões estáveis do OpenTTD, ou a versão mais recente de todas (talvez com alguns erros) de conteúdo do jogo. Se és tecnicamente bom, podes até mesmo criar a tua própria construção personalizada com diferentes combinações de todos os recursos disponíveis.
The term "build" will be used throughout the rest of this document to refer to a version of the game.
An official "Release" is just that -- a stable, complete release of the game. While there may be minor bugs fixes applied to a Release, it is expected that there will be no significant changes to this build of the game, and any addition of new features will come in a future version.
A Release of OpenTTD is just like the release of any software package, and is numbered accordingly. For example, the latest Release of OpenTTD is 1.10.3. Major Releases versions are denoted by the either the first and second number, while Minor Releases are represented by the third number.
Release Candidate (RC or testing)
You can think of this as a proposed Release. A Release Candidate build is a Release in the making. While minor features may be added to an RC, for the most part, the feature list is frozen.
What separates an RC from a Release is simply the amount of testing and bug fixing left to do. An RC can be expected to be fairly stable, but there still may be bugs with certain functionality.
A Release Candidate is numbered as such: [Release version] RC[Candidate number]
So, for example, the last RC of OpenTTD was 1.2.0 RC3. Once the RC will be confirmed stable enough, it will become a full-fledged release as 1.2.0.
RCs should always be fairly stable, so if one is available, it is recommended to use it rather than miss out on its new features by reverting back to an official Release. An RC is simply a Release with a bit of polishing needed.
Nightly Build (Nightly)
"Nightly builds" are generally works-in-progress. A nightly will contain OpenTTD's cutting-edge features (usually features planned for the next Release), but can expected to be unstable and buggy. Nightlies have the potential to corrupt your saved games, so you should backup all your important data files before installing a nightly build.
As the name suggests, nightly builds are compiled frequently, and thus new features become available in OpenTTD on a regular basis. If you find yourself hearing about a feature of OpenTTD, but don't see it in your version, it was most likely released in a nightly build. Weigh the risks (which are substantially lowered by backing up your data -- get the hint? ), and install a nightly if you want a feature not yet available in a Release or an RC.
Nightly builds have a different numbering schema than Releases do. A nightly version will be numbered like: r8642
The term "trunk" (as in the trunk of a tree) refers to the main development environment for the developers of OpenTTD (contrast this with the "branch" terminology described below). The trunk contains code either developed or approved by the core developers of the game. The code contained in the trunk is anticipated to make its way into an official Release. By extension, code found in the trunk can be thought of as the "official" code of OpenTTD.
Nightly builds, as described above, will always contain the latest code "in the trunk." Thus, if you see a feature described as "in the trunk", you can be sure it will be available in the next nightly build, if it is not already.
Branch or SVN Branch
Usually an "SVN Branch" is created for a specific feature, feature set, or functionality that is being developed as a candidate for inclusion in the trunk (and eventually in a Release), but is still very much "on probation". SVN branches have not been tested with the other, latest features of OpenTTD, and therefore may corrupt or undo the work other developers have done. The work being done on a branch is independent of work being done in the trunk. Think again in terms of a tree -- a branch originates from the trunk, but grows out from it.
If an SVN branch can be verified by other developers as stable both within itself and in conjunction with features being developed elsewhere, the branch may be later merged back into the effort as part of a nightly. Until this is confirmed, however, there are no guarantees that features from one branch will work with those from another. It is recommended that if you want to utilize features being developed in an SVN branch, you start with the build at which point the SVN branched off, and then install the code from the branch.
So, for example, if the latest nightly version was released on Friday, but the SVN branch code has been a separate development effort since Monday, you should work from the nightly that was released on Monday, and then install the SVN branch atop it.
As you can see, this is a feature tradeoff -- you get the feature(s) in the branch that you want, but you probably do not get the latest features released in the main branch/trunk.
Just like nightlies, SVN branches should be expected to be buggy and perhaps unstable. In addition, SVN branches typically have been subjected to less testing than the main branch (i.e. fewer sets of eyes have looked at the code), which makes them potentially even less stable.
A "patch", generally speaking, is a bit of code or functionality developed by someone outside of the core developers of the game. This does not necessarily imply that a patch is in some way inferior to the trunk code, it just means that it contains functionality and/or code that has not (yet) been approved for inclusion in a future release of the game.
Whereas work on the trunk (and to a lesser extent, an SVN branch) is done by a discrete set of developers, patches can be created by anyone. This opens up great possibilities for creativity and new functionality, but also introduces a higher risk factor because, well, patches can be created by anyone.
Patches cannot be directly installed like nightlies can -- they must be compiled on a user's machine.
See also: How to apply patches on the forums
Main Article: Mini Integrated Nightly (en)
The MiniIN is a development environment separate from the trunk that contains the trunk code plus many user patches. After the release of 0.5.0, the MiniIN will no longer be updated with the trunk code. At that stage the MiniIN will be 0.5.0 plus all the user patches.
Which version of OpenTTD should I install?
Start with the latest Release (or Release Candidate, if there is one). Go to the OpenTTD Downloads page. The latest stable version should always be listed there.
Many people are satisfied with the major Releases. If, however, you hear about a feature you'd like to have, then download the latest nightly on top of your stable version (remember, back up your saved games!)
Only if you feel like you've really got this version thing down (in which case, why are you reading this?) should you try to install an SVN branch build.
I heard someone talking about [x feature]. Why don't I have that in my game?
You could have a different build installed. Many of the newest (and sometimes coolest) features are only part of a nightly (i.e. in the Trunk) at this point, though they hopefully will be part of a future Official Release.
If you know you have the right version installed it may be able to be turned on in the Advanced Settings window.
How do I keep track of what features are where?
- An overview of major features included or planned in various Releases can be found under Roadmap (en)s
- Details of recent changes to the trunk are here