Difference between revisions of "Road To 1.0"
From Free Pascal wiki
Jump to navigationJump to search| Line 2: | Line 2: | ||
This documents helps the lazarus team to focus on a 1.0 release in the near future. | 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 | + | The work to be done is divided into 2 targets: |
| − | |||
* things to be done before [[Road To 1.0#0.9.12 | 0.9.12]] | * things to be done before [[Road To 1.0#0.9.12 | 0.9.12]] | ||
* things to be done before the [[Road To 1.0#1.0 | 1.0 release]] | * things to be done before the [[Road To 1.0#1.0 | 1.0 release]] | ||
| Line 15: | Line 14: | ||
* 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. | * 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. | * 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.12== | ==0.9.12== | ||
Revision as of 09:50, 9 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 2 targets:
- 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.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
