Lazarus Development Process
│
English (en) │
français (fr) │
русский (ru) │
Who are developers
You can find a recent list of lazarus developers here: Developer pages
You can find history of lazarus developers here: History
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
TODOs
- Lazarus 0.9.30 todo
Lazarus 0.9.28 todoLazarus 0.9.26 todoDetailed Lazarus 0.9.24 todoDetailed Lazarus 0.9.22 todo- Detailed Lazarus release template todo
Ideas
Roadmaps
- 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 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 release
Target | Responsible | Comment |
---|---|---|
1.0.0 | Vincent | |
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 | - | Debugger options |
1.0.0 | - | Doc Editor |
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
Target | Responsible | Comment |
---|---|---|
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's helps the Lazarus developers to choose the branching policy for the Lazarus 1.0 release. Below two alternatives are presented. Time goes from left to right; the different branches are shown vertically. B indicates a branch point, T a tag (release).
Alternative 1: 1.0 is released from the branch that has 0.9.30
0.9.30(1.0.RC1) 0.9.30.2(1.0.RC2) 1.0.0 1.0.2 | | | | fixes_1_0: ---- T - 0.9.30.1 --- T - 0.9.30.3 ----- 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-- 1.1 --------------------------------------------------B------- 1.3 ------------ Developing for 1.4 or 2.0
In this alternative trunk will be branched and become version 1.1. From the branch called fixes_1_0 a 0.9.30 release will be made. Further fixes from trunk will be merged to this branch, so it can become stable and contain more fixes so we can release it as 1.0.0. After this release, the fixes_1_0 branch will keep alive for more bug fix releases.
In the meantime, development in trunk will go on and will lead to a branch point for the fixes_1_2 branch, from which a Lazarus 1.2.0 will be released.
Alternative 2: fixes_1_0 branch is branched after the release 0.9.30 from trunk
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.9.32(1.0.RC1) 1.0.0 1.0.2 | | | | fixes_1_0: | ------ T - 0.9.32.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