Version Numbering

From Free Pascal wiki
Revision as of 08:30, 17 February 2011 by Ggeldenhuys (talk | contribs) (updated graph to reflect latest state of the subversion repository)
Jump to navigationJump to search

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

Explanation of the different version numbers of Lazarus

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 0.9.16 is released, and will never change, ever.

But the developers are working in an ongoing version, which changes every day. Those versions have odd last numbers. Thus after the moment that 0.9.16 was released, the developers were working on version 0.9.17. This version is maintained using SVN (Getting Lazarus), every patch gets a 'revision'-number.

For example, at the moment of writing this the current SVN/0.9.13 version has revision 8792. 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 this bug as an example. The target is the version in which the developers aim to get this problem fixed. In this case this means that version 0.9.12 can't be released if this bug is not fixed. This way we also have a nice list of bugs that has to be solved before a version can be released. You can see this list in the bug-tracker, using the appropiate filter.

You can see that bug 1227 is solved in revision 8004. Thus all versions with a revision number higher then 8004 must contain this patch. The revision number of version 0.9.10 is 7919, thus this fix is not included in that version. But the fix will be in the first version that will be released; version 0.9.12. Of course it's also available in the unstable svn-versions (0.9.11).

Version numbers in graph form

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

o - trunk has version 0.9.25: development + experimental stuff
|
|\
| \
|  |
|  o - (branches\fixes_0.9.26) - feature freeze + release candidate
|  |\ 
|  | o - (tags\release_0_9_26)
|  |
|  o - (branches\fixes_0.9.26) - some fixes and low impact new features were added from trunk to 0.9.26.1
|  |\
|  | o - (tags\0.9.26.2) - release 0.9.26.2 from the fixes branch.
|  |
|  o - some fixes from trunk were applied to 0.9.26.3, but no release was made.
|
o - trunk becomes version 0.9.27
|
|
|\
| \
|  |
|  o - (branches\fixes_0.9.28) - feature freeze + release candidate, still version 0.9.27
|  |\
|  | o - (tags\release_0_9_28) - this will happen in the future
|  |
|  o - (branches\fixes_0.9.28) - some fixes and low impact new features will be added from trunk to 0.9.28.1
|
o - trunk becomes version 0.9.29
|
|
|\
| \
|  |
|  o - (branches\fixes_0.9.30) - feature freeze + release candidate, still version 0.9.29
|  |\
|  | o - (tags\release_0_9_30) - this will happen in the future soon
|  |
|  o - (branches\fixes_0.9.30) - some fixes and low impact new features will be added from trunk to 0.9.30.1
|
o - trunk becomes version 0.9.31: continued development + experimental stuff


Note that trunk gets a new version right after branching. So version 0.9.31 from trunk exists at the same time as version 0.9.30 or 0.9.30.1 in branches\fixes_0.9.30.