Difference between revisions of "OOo30 release engineering planned changes"
From Apache OpenOffice Wiki
m (Add more Categories) |
(disclaimer added) |
||
| Line 1: | Line 1: | ||
The OpenOffice 3.0 code line will be the first chance in many years to do a number of changes which will break the strict binary compatibility and patching requirements on the current SRC680 code line. | The OpenOffice 3.0 code line will be the first chance in many years to do a number of changes which will break the strict binary compatibility and patching requirements on the current SRC680 code line. | ||
| − | The following is a short list of changes which are planned before the first release of OOo on the new codeline. | + | The following is a short list of changes which are planned before the first release of OOo on the new codeline. Please note that it's just the result of a short brainstorming session. We have not yet fully evaluated whether all those things will be possible. And we do not yet have working concepts for everything. |
* most important: overhaul the windows symbol->ordinal mapfile system (known as def-files) | * most important: overhaul the windows symbol->ordinal mapfile system (known as def-files) | ||
Revision as of 09:07, 9 November 2007
The OpenOffice 3.0 code line will be the first chance in many years to do a number of changes which will break the strict binary compatibility and patching requirements on the current SRC680 code line.
The following is a short list of changes which are planned before the first release of OOo on the new codeline. Please note that it's just the result of a short brainstorming session. We have not yet fully evaluated whether all those things will be possible. And we do not yet have working concepts for everything.
- most important: overhaul the windows symbol->ordinal mapfile system (known as def-files)
- reconsider the base line (target-system) for all platforms
- update all compilers on all platforms to the latest and greatest consistent with the reconsidered baseline
- move localization files out of source modules into their own place
- get rid SUPD dependencies (including library and resource names)
- get rid of STLport, use system STL where applicable
- overhaul the 3rd-party library patch system
- overhaul build.lst system with a XML based one
- 64 bit support for all platforms
- fix precompiled-header for Windows with .Net-2005 compiler
- revisit all places with disabled optimizations
- reconsider used and supported jdk-versions
- revisit compiler-defines (for example WIN_VER) and linker switches
Not RE tasks but important:
- overhaul pack, installation and patch system
- make resource system independent of source code tree
- get rid of complete mozilla source tree inside OOo source tree
