Version Numbering

Deutsch (de) | English (en) | español (es) | 日本語 (ja) | русский (ru)

FPC, Lazarus combinations

Lazarus Release	Recommended FPC version	Notes
0.9.24 - 0.9.99	2.2.4
1.0.0 - 1.0.6	2.6.0
1.0.8 - 1.2.2	2.6.2
1.2.4 - 1.4.2	2.6.4
1.6.0 - 1.6.2	3.0.0	last version for Win98/ME using fpc 2.6.4
1.6.4	3.0.2
1.8.0 - 2.0.8	3.0.4
2.0.10	3.2.0
2.2.0 and newer	3.2.2

(See also: Free Pascal)

Explanation of the different version numbers of Lazarus

Lazarus 3.0 and newer

As of Lazarus version 3.0, the versioning numbering has changed.
The release part of the full version number is no longer maintained. While still included in the full version value, the release number will always be 0 (zero) starting with version 3.0.
Major and minor version numbers are used to identify a release or a fixes branch.

An even minor version number, like 3.0 or 3.2, represents a general availability release.
An odd minor version number no longer indicates that it is a development (or trunk) version. Instead, an odd minor version number like 3.1 or 3.3 represents a fixes branch. For example: 3.1 would contain bug fixes for the 3.0 release and would be used as the basis for the 3.2 release.
Development (or trunk) versions are always represented as minor version number 99; i.e. 3.99 is the development branch for the future 4.0 release. Also, selected commits from this branch are cherry picked to the 3.X family.

Patch numbers identify a release candidate or a general availability release. For example: 3.0.0 RC1 has the the full version value of 3.0.0.1. RC2 has the value 3.0.0.2, and the released product could be 3.0.0.3.

Pre 3.0 versioning

The most important thing to know is that if the last number of the version is an even value, it's a stable/published release. For example version 1.4.2 is released, and will never change, ever.

But the developers are working on two ongoing versions, which change every day. Those versions have odd last numbers. There is the fixes branch using the version 1.4.3 and the development trunk using the version 1.5. The fixes branch only receives bug fixes and will eventually be released as 1.4.4. The development version 1.5 receives bug fixes and new features. These versions are maintained using SVN (Getting Lazarus), every patch gets a 'revision'-number.

For example, at the moment of writing this the current SVN/1.7 version has revision 50714. It's available via SVN. Every night some snapshots are built from the current revision.

How about fixed bugs, in which version is the fix included?

Take the issue [1] as an example.

It has a "milestone" set ("version 3.0").

• For open bugs the milestone indicates the currently planed target by witch the issue should be fixed. It may however be rescheduled.
• For closed issues, it is set to the release that will contain the issue.

Some issues also refer to the commit containing the fix. Usually the last "mentioned in commit" note. Or a dedicated comment by a developer. In this case [2]

On that commit page is the following info (needs to be unfolded)

   Branches containing this commit
   fixes_3_0 main
   Tags containing this commit
   lazarus_3_0_RC1 main_3_99 t-fixes-3

`lazarus_3_0_RC1` is the indicator that it will be in the 3.0 release (after the RC, in which it also is included)

Some older issues, that were imported from mantis have tags named "target". [3]

In the "mantis" block is the info "Fixed in revision" which links to a commit, as described above.

Version numbers in graph form

Maybe this will help some users understand the version numbering a bit better.

o - trunk becomes version 1.5: development + experimental stuff, fixes branch 1.4 is created
|
|\
| \
|  |
|  o - (branches\fixes_1_4) - feature freeze + release candidate, based on 1.3
|  |\ 
|  | o - (tags\release_1_4_RC1)
|  |\ 
|  | o - (tags\release_1_4_2)
|  |\ 
|  | o - (tags\release_1_4_4)
|
o - trunk becomes version 1.7: development + experimental stuff, fixes branch 1.6 is created
|
|\
| \
|  |
|  o - (branches\fixes_1_6) - feature freeze + release candidate, based on 1.5
|  |\ 
|  | o - (tags\release_1_6_RC1)
|  |\
|  | o - (tags\release_1_6) - this will happen in the future

Note that trunk gets a new version right after branching. So version 1.7 from trunk exists at the same time as version 1.6RC1 in branches\fixes_1_6.