Projects/KDevelop5/ReleaseTodo: Difference between revisions
Appearance
< Projects
No edit summary |
No edit summary |
||
Line 16: | Line 16: | ||
* see a doctor | * see a doctor | ||
= bof notess = | |||
* remove oldcpp | |||
* not even keep it around for installing both | |||
* we'll keep .kdev4 in project files and config folder names | |||
* we'll add migration code | |||
* shortcuts: streamline them, desirable. but try to keep compatibility if possible by setting old shortcut as alternative. maybe offer the possibility to import old shortcuts via kxmlgui (which is broken?, but could be fixed/done). while at it: add emacs, vim, visual studio short cut sets etc. | |||
* also: make sure to document new shortcuts | |||
* for the release announcement of beta 1: | |||
** market it as a tech preview, still api can be changed | |||
** clearly document regressions and new features - why is it better, even though some wizards/features got removed, and why is it still OK to go ahead with this functionality | |||
** create an ehterpad for the release announcements |
Revision as of 10:49, 28 July 2015
things left to do
- migrate settings form ~/.kde(4) to ~/.local, see https://community.kde.org/Frameworks/Porting_Notes#Migrating_configuration
- move oldcpp out of kdevelop
- merge kdev-clang into kdevelop (?)
- make it possible to install both
- integrate KTextEditor plugins, hide those we do not want
- release kdev-qmljs, kdev-qmake, kdev-ruby (?), kdev-css (?)
kdev-clang blockers
- implement functions is broken
- add include helper
get a vision
- see a doctor
bof notess
- remove oldcpp
- not even keep it around for installing both
- we'll keep .kdev4 in project files and config folder names
- we'll add migration code
- shortcuts: streamline them, desirable. but try to keep compatibility if possible by setting old shortcut as alternative. maybe offer the possibility to import old shortcuts via kxmlgui (which is broken?, but could be fixed/done). while at it: add emacs, vim, visual studio short cut sets etc.
- also: make sure to document new shortcuts
- for the release announcement of beta 1:
- market it as a tech preview, still api can be changed
- clearly document regressions and new features - why is it better, even though some wizards/features got removed, and why is it still OK to go ahead with this functionality
- create an ehterpad for the release announcements