Difference between revisions of "Lazarus Development Process"

From Lazarus wiki
(Alternative 3 added)
(fixes_1_0 branch will have version 0.99.1 after branching from trunk)
Line 124: Line 124:
 
fixes_0_9_30:        ---- T - 0.9.30.1 --- T - 0.9.30.3 --- End of life
 
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         
+
                     |                           0.99.2(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
+
fixes_1_0:          |                    - 0.99.1 -T - 0.99.3 ----- T - 1.0.1 -- T -- 1.0.3 ---- End of life
 
                     |                  /
 
                     |                  /
 
                     |                  /                                                1.2.0        1.2.2          1.2.4
 
                     |                  /                                                1.2.0        1.2.2          1.2.4
Line 141: Line 141:
 
release_0_9_30:      0.9.30
 
release_0_9_30:      0.9.30
 
                     /   
 
                     /   
                     |                         0.9.32(1.0.RC1)  1.0.0        1.0.2         
+
                     |                           0.99.2(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
+
fixes_1_0:          |                    - 0.99.1 -T - 0.99.3 ----- T - 1.0.1 -- T -- 1.0.3 ---- End of life
 
                     |                  /
 
                     |                  /
 
                     |                  /                                                1.2.0        1.2.2          1.2.4
 
                     |                  /                                                1.2.0        1.2.2          1.2.4

Revision as of 13:52, 17 November 2010

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.9.28) - 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.9.30 release notes
  2. Lazarus 0.9.28 release notes
  3. Lazarus 0.9.26 release notes
  4. 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.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 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 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.99.2(1.0.RC1)  1.0.0        1.0.2        
                    |                              |                |            | 
fixes_1_0:          |                    - 0.99.1 -T - 0.99.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-- 0.9.31 ------B- 1.1 ----------------------------------------B------- 1.3 ------------ Developing for 1.4 or 2.0 

Given the fact we want to release 0.9.30 asap, we should not wait to long to branch trunk for that release. If we branch too early, then many fixes still need to be merged to the fixes_1_0 branch. Therefore I propose to 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, while still being able to get fixes for Lazarus 1.0 into trunk before branching the fixes_1_0 branch.

Alternative 3: fixes_1_0 branch is branched after the release 0.9.30 from trunk, no 0.9.30.x branch

release_0_9_30:       0.9.30
                     /  
                    |                            0.99.2(1.0.RC1)  1.0.0        1.0.2        
                    |                              |                |            | 
fixes_1_0:          |                    - 0.99.1 -T - 0.99.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 --T-- 0.9.31 ------B- 1.1 ----------------------------------------B------- 1.3 ------------ Developing for 1.4 or 2.0 

In this case it's just: release 0.9.30 soon, really soon. There has to be a fpc 2.4.2 release early. Then, as long as the developers can hold there breath and keep new, 'dangerous' commits for themselves, or place them between ifdef's, do not branch (maybe for another month?). so the 0.9.31 branch can evolve into version 1.0. Until there is something new, so the 1.0 and 1.1 (trunk) branches are made.

See also