Difference between revisions of "Road To 1.0"
From Lazarus wiki
Jump to navigationJump to search (→1.0) |
|||
Line 9: | Line 9: | ||
==1.0 or after 1.0== | ==1.0 or after 1.0== | ||
− | 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.0, that will mean, the developers think this bug is not important enough to block a 1.0 release. In order to have a 1.0 rather sooner than later, developers will leave those bugs for later. Of course patches for these issues | + | 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.0, that will mean, the developers think this bug is not important enough to block a 1.0 release. In order to have a 1.0 rather sooner than later, developers will leave those bugs for later. Of course you can make sure these post -1.0 issues are fixed in the 1.0 release by providing patches for these issues. |
Some criteria are: | Some criteria are: |
Revision as of 22:39, 1 October 2005
This documents helps the lazarus team to focus on a 1.0 release in the near future.
The work to be done is divided into 3 targets:
- things to be done before the next release 0.9.10
- things to be done before 0.9.12
- things to be done before the 1.0 release
- things to be done after the 1.0 release
1.0 or after 1.0
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.0, that will mean, the developers think this bug is not important enough to block a 1.0 release. In order to have a 1.0 rather sooner than later, developers will leave those bugs for later. Of course you can make sure these post -1.0 issues are fixed in the 1.0 release by providing patches for these issues.
Some criteria are:
- Only gtk1 and win32 widget sets are stable in 1.0. So bugs for other widget set (gtk2, carbon) are set to post 1.0.
- Until the 1.0 there will be a feature freeze. New features and components generally get a post 1.0 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.
0.9.10
- Webbugs to be fixed before the next release: target 0.9.10 bugs
Remove fpc 1.0 specific code.Use UTF8 for all translations.
0.9.12
- Webbugs to be fixed before the next release: target 0.9.12 bugs
1.0
- Webbugs to be fixed before the 1.0 release: target 1.0 bugs
check and warn when open form for uninstalled packages with registration- doc editor
- more LCL Documentation (see LCL Documentation Roadmap)
- fix debugging in windows and linux
start protocol: IDE should remember if there is a problem opening a form or project and should not open it on a second startimprove make install target
After 1.0
- Webbugs to be fixed after the 1.0 release: target post 1.0 bugs