Lazarus Development Process

From Free Pascal wiki
Jump to navigationJump to search

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

  1. Lazarus 0.9.30 todo
  2. Lazarus 0.9.28 todo
  3. Lazarus 0.9.26 todo
  4. Detailed Lazarus 0.9.24 todo
  5. Detailed Lazarus 0.9.22 todo
  6. Detailed Lazarus release template todo

Ideas

  1. IDE Development

Roadmaps

  1. Current Roadmap (v.0.99.0) - Roadmap of current Lazarus version (There are roadmap of Lazarus 1.0.0 too)
  2. Roadmap - Current status of the some parts of Lazarus (IDE, LCL and others)
  3. Icon Editor Roadmap - Roadmap of Icon Editor Tool
  4. LCL Documentation Roadmap - Roadmap of LCL Documentation

What we have done

  1. Lazarus 0.99.0 release notes - in progress
  2. Lazarus 0.9.30 release notes
  3. Lazarus 0.9.28.2 release notes
  4. Lazarus 0.9.28 release notes
  5. Lazarus 0.9.26 release notes
  6. Lazarus 0.9.24 release notes

What we will not do

  1. Lazarus known issues (things that will never be fixed)

Road to 1.0

The work to be done is divided into 3 targets:

  • things to be done before the next release (0.99.0): 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 Find out, if Lazarus configuation files can be stored in the profile directory under windows implemented in 0.9.26
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 lazdoc: inherited properties/methods
1.0.0 various Help for common IDE items (see IDE Documentation Roadmap)
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.

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 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.

See also