Lazarus Development Process
Who are developers
Setting the target of a bugfix
When new bugs are entered, we try to give them a target in which version the bug will be fixed. If a bug is set to post 1.2, that means the developers think this bug is not important enough to block a 1.0 release. In order to have a 1.0 sooner rather than later, developers will leave those bugs for later. Of course you can make sure these post 1.2 issues are fixed in the 1.0 release by providing patches for these issues.
Some criteria are:
- Only gtk2 and win32 widget sets are stable in 1.0. Bugs for other widget set (qt, carbon) are set to post 1.2.
- Until the 1.0 there will be a feature freeze. New features and components generally get a post 1.2 target. Bugs affecting stability have a higher priority than bugs fixing the implementation of a property.
- Some components are not stable enough and should be disabled for 1.0. If they are disabled, then fixing them before 1.0 will not be necessary.
What we are planing to do
- Lazarus 0.9.30 todo
Lazarus 0.9.28 todo Lazarus 0.9.26 todo Detailed Lazarus 0.9.24 todo Detailed Lazarus 0.9.22 todo
- Detailed Lazarus release template todo
- Current Roadmap (v.0.9.28) - Roadmap of current Lazarus version (There are roadmap of Lazarus 1.0.0 too)
- Roadmap - Current status of the some parts of Lazarus (IDE, LCL and others)
- Icon Editor Roadmap - Roadmap of Icon Editor Tool
- LCL Documentation Roadmap - Roadmap of LCL Documentation
What we have done
- Lazarus 0.9.30 release notes
- Lazarus 0.9.28.2 release notes
- Lazarus 0.9.28 release notes
- Lazarus 0.9.26 release notes
- Lazarus 0.9.24 release notes
What we will not do
Road to 1.0
The work to be done is divided into 3 targets:
- things to be done before the next release (0.9.28): patches, regressions, some steps towards 1.0 chosen by developers, bug fixes
- things to be done before the 1.0 release: make Lazarus ready for a 1.0 release
- things to be done after the 1.0 release: less important bugs, support for new widgetsets and new features
|1.0.0||Vincent||Find out, what needs to be done to make it possible to install Lazarus in c:\Program Files\Lazarus (note space in path).|
|1.0.0||Mattias||gtk2 TSpeedButton mouse enter/leave on TPageControl|
|1.0.0||Mattias||lazdoc: inherited properties/methods|
|1.0.0||various||Help for common IDE items (see IDE Documentation Roadmap)|
|1.0.0||Marc||Using icons to set form and application icon.|
|1.0.0||Marc||Using imagelist for listview images|
|1.0.0||Tombo||Icon editor (see Icon Editor Roadmap)|
|1.0.0||various||Webbugs to be fixed before the 1.0 release: target 1.0 bugs|
|1.0.0||-||more LCL Documentation (see LCL Documentation Roadmap)|
|1.0.0||Marc||fix debugging in windows and linux|
|1.0.0||-||add framework for easily using resourcestrings and translations in applications. Mattias started this already. It works more or less for custom packages, but not yet for the auto-install packages like the LCL.|
|1.0.0||Mattias||gtk2 interface: recognize and translate dead keys|
After the 1.0 release
|post 1.0||-||Webbugs to be fixed after the 1.0 release: target post 1.2 bugs|
|post 1.0||Mattias||IDE Feature: Visual Form inheritance|
|post 1.0||Mattias||IDE Feature: lazdoc for translations|
Lazarus branches / version numbers around 1.0
This ascii - art schema shows what the Lazarus developers have chosen as branching policy for the Lazarus 1.0 release. Time goes from left to right; the different branches are shown vertically. B indicates a branch point, T a tag (release).
0.9.30 0.9.30.2 | | fixes_0_9_30: ---- T - 0.9.30.1 --- T - 0.9.30.3 --- End of life / | 0.99.0(1.0.RC1) 1.0.0 1.0.2 | | more RCs | | fixes_1_0: | ------T - 0.99.1 -< .. >-- T - 1.0.1 -- T -- 1.0.3 ---- End of life | / | / 1.2.0 1.2.2 1.2.4 | / | | | fixes_1_2: | | ----- T - 1.2.1 --- T - 1.2.3----- T - 1.2.5 ---- End of life | | / | | | trunk: --- 0.9.29 --B-- 0.9.31 ------B- 1.1 -------------------------------------B------- 1.3 ------------ Developing for 1.4 or 2.0
Given the fact we want to release Lazarus 0.9.30 asap, we should not wait to long to branch trunk for that release. Because we still want to fix a lot of issues for 1.0, using the same branch for the release candidates and Lazarus 1.0 means we have to merge a lot of fixes to that branch. Therefore we use separate branches for 0.9.30 and 1.0.0. This postpones branching for 1.0 and makes it possible to release a fpc 2.4.2 based Lazarus rather soon (0.9.30), while still being able to get fixes for Lazarus 1.0 into trunk before branching the fixes_1_0 branch. Note: releases beyond 0.9.30 from the fixes_0_9_30 depend on the fact that a volunteer is found who merges from trunk to that branch.