Re: Porting notes / deprecation docs
Am Dienstag, 13. Juli 2021, 18:46:35 CEST schrieb Frederik Schwarzer: > On 7/12/21 8:43 PM, Friedrich W. H. Kossebau wrote: > > IIRC main file of the generation is > > https://invent.kde.org/websites/quality-kde-org/-/blob/master/apidox/src/ > > gendox.sh > > > > But I dropped out when there were people talking about their progress in > > writing a replacement and put my hopes & bet on them. But seems life got > > in > > then it seems... > > I cannot check what is used on the server but I was told > https://invent.kde.org/frameworks/kapidox/-/blob/master/src/kapidox_generate > would be the script that generates apidocs on the server. quality-kde-org code still is the one being run, and it invokes kapidox_generate in the process Cheers Friedrich
Re: Porting notes / deprecation docs
On 7/12/21 8:43 PM, Friedrich W. H. Kossebau wrote: Am Montag, 12. Juli 2021, 20:22:30 CEST schrieb Frederik Schwarzer: On 7/12/21 7:38 PM, Friedrich W. H. Kossebau wrote: Now what is meant by "clickable links to replacements" exactly? Any example for what you have in mind? (Just in case, Doxygen usually itself already generated automatic links to the functions (just needs complete signature, incl. const), see also https://www.doxygen.nl/manual/autolink.html but then I would guess you know that) Yes, that's what I meant. api.k.o does have clickable links (if done properly) but compiler warnings do not. That's why it would be good to keep the KF5 api docs. Ah, so html pages on a server/local docs in QCH vs. compiler log, I see :) If we put URLs in the messages, we could click them in Konsole. ;) Any insight on how you kept the KDE 2-4 apidocs alive? Mainly defending against admin wanting to clean up dead stuff and just wiping the current freak setup behind api.kde.org ;) (which is https:// invent.kde.org/websites/quality-kde-org) Right now the kdelibs 2-4 docs are no longer regenerated (at the time when I got involved only the 4 one still was, but now also no longer is, and just is static files on the web server. I did some URL updates e.g. for trolltech.com- qt.io using mass regexp replacements on them). IIRC main file of the generation is https://invent.kde.org/websites/quality-kde-org/-/blob/master/apidox/src/ gendox.sh But I dropped out when there were people talking about their progress in writing a replacement and put my hopes & bet on them. But seems life got in then it seems... I cannot check what is used on the server but I was told https://invent.kde.org/frameworks/kapidox/-/blob/master/src/kapidox_generate would be the script that generates apidocs on the server. Maybe someone can clarify? CHeers, Frederik
Re: Porting notes / deprecation docs
Am Montag, 12. Juli 2021, 20:22:30 CEST schrieb Frederik Schwarzer: > On 7/12/21 7:38 PM, Friedrich W. H. Kossebau wrote: > > Now what is meant by "clickable links to replacements" exactly? Any > > example > > for what you have in mind? > > (Just in case, Doxygen usually itself already generated automatic links to > > the functions (just needs complete signature, incl. const), see also > > https://www.doxygen.nl/manual/autolink.html > > but then I would guess you know that) > > Yes, that's what I meant. api.k.o does have clickable links (if done > properly) but compiler warnings do not. That's why it would be good to > keep the KF5 api docs. Ah, so html pages on a server/local docs in QCH vs. compiler log, I see :) ((Old man blabla: decades ago one would have hoped we have more machine- processable output from compilers in 2021, e.g. rich text. But then we also still do patches as plain text diffs, not AST diffs... oh well :) )) > Any insight on how you kept the KDE 2-4 apidocs alive? Mainly defending against admin wanting to clean up dead stuff and just wiping the current freak setup behind api.kde.org ;) (which is https:// invent.kde.org/websites/quality-kde-org) Right now the kdelibs 2-4 docs are no longer regenerated (at the time when I got involved only the 4 one still was, but now also no longer is, and just is static files on the web server. I did some URL updates e.g. for trolltech.com- >qt.io using mass regexp replacements on them). IIRC main file of the generation is https://invent.kde.org/websites/quality-kde-org/-/blob/master/apidox/src/ gendox.sh But I dropped out when there were people talking about their progress in writing a replacement and put my hopes & bet on them. But seems life got in then it seems... Cheers Friedrich
Re: Porting notes / deprecation docs
On 7/12/21 7:38 PM, Friedrich W. H. Kossebau wrote: Some hopefully helpful quick comments from couch: Am Montag, 12. Juli 2021, 19:14:17 CEST schrieb Frederik Schwarzer: - If not documented separately, should existing deprecation messages be improved? "no known users" might not be enough for the "unknown users" in 3rd-party applications who get that message Yes, ideally that should be backed up by some web page perhaps, informing anyone how to get in touch with whom to make a user and their needs known, for finding a solution. - Is it possible/desirable to keep the latest KF5 API docs as it is generated on api.k.o to have deprecation messages with clickable links to replacements? When doing my own little contributions to keep api.kde.org alive last year, I also made sure to have the so far existing kdelibs 2-4 API still available, see https://api.kde.org/history.php (reached via "Old KDE Versions" from api.kde.org mainpage). The same hopefully can be done for KF5 (and other libraries who would need versioned docs). Now what is meant by "clickable links to replacements" exactly? Any example for what you have in mind? (Just in case, Doxygen usually itself already generated automatic links to the functions (just needs complete signature, incl. const), see also https://www.doxygen.nl/manual/autolink.html but then I would guess you know that) Yes, that's what I meant. api.k.o does have clickable links (if done properly) but compiler warnings do not. That's why it would be good to keep the KF5 api docs. Any insight on how you kept the KDE 2-4 apidocs alive? Cheers, Frederik
Re: Porting notes / deprecation docs
Some hopefully helpful quick comments from couch: Am Montag, 12. Juli 2021, 19:14:17 CEST schrieb Frederik Schwarzer: > - If not documented separately, should existing deprecation messages >be improved? "no known users" might not be enough for the "unknown >users" in 3rd-party applications who get that message Yes, ideally that should be backed up by some web page perhaps, informing anyone how to get in touch with whom to make a user and their needs known, for finding a solution. > - Is it possible/desirable to keep the latest KF5 API docs as it is >generated on api.k.o to have deprecation messages with clickable links >to replacements? When doing my own little contributions to keep api.kde.org alive last year, I also made sure to have the so far existing kdelibs 2-4 API still available, see https://api.kde.org/history.php (reached via "Old KDE Versions" from api.kde.org mainpage). The same hopefully can be done for KF5 (and other libraries who would need versioned docs). Now what is meant by "clickable links to replacements" exactly? Any example for what you have in mind? (Just in case, Doxygen usually itself already generated automatic links to the functions (just needs complete signature, incl. const), see also https://www.doxygen.nl/manual/autolink.html but then I would guess you know that) Cheers Friedrich
Re: Porting notes / deprecation docs
Hi, so there has been a bit more discussion in today's KF6 weekly meeting about how to proceed with porting docs. - Porting documentation needs an entry page pointing to the several resources like C++ deprecations, Qt6 porting guides, KF6 porting notes - KF6 porting notes should follow a similar approach like Qt6 porting (first compile with the latest KF5 version, which will be part of distros for quite some time and get rid of all deprecation warnings and then make it compile against KF6) - Might it be a good idea to document a selected set of API deprecations to have them in a readable format? Candidates are ones where it needs more that one or two lines of explanation - If not documented separately, should existing deprecation messages be improved? "no known users" might not be enough for the "unknown users" in 3rd-party applications who get that message - Is it possible/desirable to keep the latest KF5 API docs as it is generated on api.k.o to have deprecation messages with clickable links to replacements? Opinions/additions? Cheers, Frederik On 7/11/21 2:24 PM, Frederik Schwarzer wrote: Hi, On 7/10/21 11:54 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 22:47:58 CEST schrieb Frederik Schwarzer: Hi, On 7/10/21 7:38 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: as mentioned earlier Any pointers? :) It was discussed in the weekly BBB meetings a few weeks ago. I see. As contributor on occasions only myself, please refer to the respective meeting notes some thankfully write, so one can read up on more background, and such a planned task ideally would be backed up by a task board entry on phabricator, so people can coordinate and track things about it in an async manner. https://mail.kde.org/pipermail/kde-frameworks-devel/2021-June/117653.html Of course that out-of-context sentence at the end does not represent properly what has been said by people then. Some follow-up discussion lead to the "just grep it and put it somewhere first" approach. What I take out of this now is that I need to be more phony about what I am planning on doing. I would like to document classes/methods/etc that are going to be deprecated during KF6 development. Can you help confused-on-first-read people by explaining what "deprecated during KF6 development" is referring to? Deprecated during KF5 development and no longer be available in KF6? Not yet deprecated due to no existing replacement, but with replacement planned in KF6? Everything that is marked deprecated when KF6 sees the light of day. Okay. Not a good idea IMHO. There should be a single place of information, and we have that already with the current KF5 API docs. I hope no-one plans to just remove them from the website, though, Well, then there are also the offline docs in QCH format as backup generated during the builds and packaged by good distributions ;) The idea is to have the APIs that are being deprecated now documented when those APIs (and with it the API docs) are removed. The audience is everyone who is starting the porting work when KF6 is already there for some time. Ideally that audience should get the recommendation to first port away from deprecated API using the last released version of KF5 and Qt6. That way they are able to do a big chunk of the work while being able to maintain a fully working state of their software, without serious regressions. Once that checkpoint is reached, then go for porting all those things which disappeared/ changed in KF6 & Qt6 without any preparations in KF5 & Qt5. Remember that this is not just KF 5 -> 6, but also Qt 5 -> 6. And perhaps even C++11 -> C++17. IMHO only those would recommend to port directly from one set of APIs to an other one without any intermediate checkppints for the working sate of the software who want to secure their job for a while, because it will take ages to fix all the regressions introduced during the port. Unless the company/community goes down in the meantime, because the ported software does not get done. BTW, even the Qt Company recommends that step-by-step approach, and they surely do want to have their customers be successful in a short time ;) -> https://doc.qt.io/qt-6/portingguide.html That is also why some of us invested so much of our time into properly tagging API with deprecations warning macros and visibility guards, so porting can be done step by step away from the old AP assisted by the compiler, always having a working software. Because we have been through some porting in KDE and learned our lessons, haven't we... ;) Yes it is manual work. However, since the documentation does not remove stuff that has been removed from the API, it's a thing of adding newer deprecation markers, which seems manageable. While perhaps it might be a nice thing to have a shortcut list of API that is deprecated in KF5 times, as
Re: Porting notes / deprecation docs
Hi, On 7/10/21 11:54 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 22:47:58 CEST schrieb Frederik Schwarzer: Hi, On 7/10/21 7:38 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: as mentioned earlier Any pointers? :) It was discussed in the weekly BBB meetings a few weeks ago. I see. As contributor on occasions only myself, please refer to the respective meeting notes some thankfully write, so one can read up on more background, and such a planned task ideally would be backed up by a task board entry on phabricator, so people can coordinate and track things about it in an async manner. https://mail.kde.org/pipermail/kde-frameworks-devel/2021-June/117653.html Of course that out-of-context sentence at the end does not represent properly what has been said by people then. Some follow-up discussion lead to the "just grep it and put it somewhere first" approach. What I take out of this now is that I need to be more phony about what I am planning on doing. I would like to document classes/methods/etc that are going to be deprecated during KF6 development. Can you help confused-on-first-read people by explaining what "deprecated during KF6 development" is referring to? Deprecated during KF5 development and no longer be available in KF6? Not yet deprecated due to no existing replacement, but with replacement planned in KF6? Everything that is marked deprecated when KF6 sees the light of day. Okay. Not a good idea IMHO. There should be a single place of information, and we have that already with the current KF5 API docs. I hope no-one plans to just remove them from the website, though, Well, then there are also the offline docs in QCH format as backup generated during the builds and packaged by good distributions ;) The idea is to have the APIs that are being deprecated now documented when those APIs (and with it the API docs) are removed. The audience is everyone who is starting the porting work when KF6 is already there for some time. Ideally that audience should get the recommendation to first port away from deprecated API using the last released version of KF5 and Qt6. That way they are able to do a big chunk of the work while being able to maintain a fully working state of their software, without serious regressions. Once that checkpoint is reached, then go for porting all those things which disappeared/ changed in KF6 & Qt6 without any preparations in KF5 & Qt5. Remember that this is not just KF 5 -> 6, but also Qt 5 -> 6. And perhaps even C++11 -> C++17. IMHO only those would recommend to port directly from one set of APIs to an other one without any intermediate checkppints for the working sate of the software who want to secure their job for a while, because it will take ages to fix all the regressions introduced during the port. Unless the company/community goes down in the meantime, because the ported software does not get done. BTW, even the Qt Company recommends that step-by-step approach, and they surely do want to have their customers be successful in a short time ;) -> https://doc.qt.io/qt-6/portingguide.html That is also why some of us invested so much of our time into properly tagging API with deprecations warning macros and visibility guards, so porting can be done step by step away from the old AP assisted by the compiler, always having a working software. Because we have been through some porting in KDE and learned our lessons, haven't we... ;) Yes it is manual work. However, since the documentation does not remove stuff that has been removed from the API, it's a thing of adding newer deprecation markers, which seems manageable. While perhaps it might be a nice thing to have a shortcut list of API that is deprecated in KF5 times, as a manifest to look-up things, ideally we find ways to auto-generate that from the existing API markup. After all KDE is a software developing community, so we should be able to automate that, no? ;) So, I can only really ask to keep documentation of KF5's deprecated API in one place, and do it properly there, with nice examples, already now useful to those who port away when they can. And that place should be the current KF5 API docs. Even more as people come and go, and having yet another place which needs to be kept even more manually up-tod-ate does not improve things, it adds more risk to have outdated unmaintained information. As you could see in review, it already now needs poking in every second review to have proper documentation. And then also do that in some separate content? What would be very good to have though IMHO, are preparations of the porting documentation of that API which is not deprecated in KF5, but will be replaced by something else in KF6 (because it cannot be done earlier for reasons). The KF6 task board should have some data about such plans. Such documentation will need a place and a structure, so also need someone to work o
Re: Porting notes / deprecation docs
Am Samstag, 10. Juli 2021, 22:47:58 CEST schrieb Frederik Schwarzer: > Hi, > > On 7/10/21 7:38 PM, Friedrich W. H. Kossebau wrote: > > Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: > >> as mentioned earlier > > > > Any pointers? :) > > It was discussed in the weekly BBB meetings a few weeks ago. I see. As contributor on occasions only myself, please refer to the respective meeting notes some thankfully write, so one can read up on more background, and such a planned task ideally would be backed up by a task board entry on phabricator, so people can coordinate and track things about it in an async manner. > >> I would like to document classes/methods/etc that > >> are going to be deprecated during KF6 development. > > > > Can you help confused-on-first-read people by explaining what "deprecated > > during KF6 development" is referring to? Deprecated during KF5 development > > and no longer be available in KF6? Not yet deprecated due to no existing > > replacement, but with replacement planned in KF6? > > Everything that is marked deprecated when KF6 sees the light of day. Okay. Not a good idea IMHO. There should be a single place of information, and we have that already with the current KF5 API docs. I hope no-one plans to just remove them from the website, though, Well, then there are also the offline docs in QCH format as backup generated during the builds and packaged by good distributions ;) > The idea is to have the APIs that are being deprecated now documented > when those APIs (and with it the API docs) are removed. > The audience is everyone who is starting the porting work when KF6 is > already there for some time. Ideally that audience should get the recommendation to first port away from deprecated API using the last released version of KF5 and Qt6. That way they are able to do a big chunk of the work while being able to maintain a fully working state of their software, without serious regressions. Once that checkpoint is reached, then go for porting all those things which disappeared/ changed in KF6 & Qt6 without any preparations in KF5 & Qt5. Remember that this is not just KF 5 -> 6, but also Qt 5 -> 6. And perhaps even C++11 -> C++17. IMHO only those would recommend to port directly from one set of APIs to an other one without any intermediate checkppints for the working sate of the software who want to secure their job for a while, because it will take ages to fix all the regressions introduced during the port. Unless the company/community goes down in the meantime, because the ported software does not get done. BTW, even the Qt Company recommends that step-by-step approach, and they surely do want to have their customers be successful in a short time ;) -> https://doc.qt.io/qt-6/portingguide.html That is also why some of us invested so much of our time into properly tagging API with deprecations warning macros and visibility guards, so porting can be done step by step away from the old AP assisted by the compiler, always having a working software. Because we have been through some porting in KDE and learned our lessons, haven't we... ;) > Yes it is manual work. However, since the documentation does not remove > stuff that has been removed from the API, it's a thing of adding newer > deprecation markers, which seems manageable. While perhaps it might be a nice thing to have a shortcut list of API that is deprecated in KF5 times, as a manifest to look-up things, ideally we find ways to auto-generate that from the existing API markup. After all KDE is a software developing community, so we should be able to automate that, no? ;) So, I can only really ask to keep documentation of KF5's deprecated API in one place, and do it properly there, with nice examples, already now useful to those who port away when they can. And that place should be the current KF5 API docs. Even more as people come and go, and having yet another place which needs to be kept even more manually up-tod-ate does not improve things, it adds more risk to have outdated unmaintained information. As you could see in review, it already now needs poking in every second review to have proper documentation. And then also do that in some separate content? What would be very good to have though IMHO, are preparations of the porting documentation of that API which is not deprecated in KF5, but will be replaced by something else in KF6 (because it cannot be done earlier for reasons). The KF6 task board should have some data about such plans. Such documentation will need a place and a structure, so also need someone to work on and prepare it, so developers can put in the data once those replacements are created during KF6 init phase. My 2 cents Cheers Friedrich
Re: Porting notes / deprecation docs
Hi, On 7/10/21 7:38 PM, Friedrich W. H. Kossebau wrote: Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: as mentioned earlier Any pointers? :) It was discussed in the weekly BBB meetings a few weeks ago. I would like to document classes/methods/etc that are going to be deprecated during KF6 development. Can you help confused-on-first-read people by explaining what "deprecated during KF6 development" is referring to? Deprecated during KF5 development and no longer be available in KF6? Not yet deprecated due to no existing replacement, but with replacement planned in KF6? Everything that is marked deprecated when KF6 sees the light of day. For that I scraped up all the deprecation macros from the frameworks and edited them to be more unified. That sounds like duplication of data, and worse, a manual copy of a certain state, which also needs to be manually maintained to be up-to-date to stay useful. In general I am also curious what audience is targeted by the planned documentation and in which work-flows that documentation should solve which needs, and what other solutions are there which would not satisfy those needs well enough? In general, for API already deprecated now during lifetime of KF5 we are adding porting notes to the very API itself. Which is also the place as API consumer I would be hoping for to get all needed information straight in one go, instead of having to jump to other places, which might even get out of sync or focus of developers (remember that current online docs of api.kde.org also only provide docs for latest version (and even the development one, not just the latest released). And this is a change to what happened in kdelibs4 times, where most deprecation happened in the development branches for what became KDE Frameworks, so there also was no API documentation maintained at the same time. So copying the approach taken for the KDE Frameworks porting notes would not be needed here 1:1 for what I understand. Instead we would need to add documentation for those things which are again deprecated (well, removed rather) during preparation of KF6, where the replacement also only will be in KF6, so no-one can port before. The idea is to have the APIs that are being deprecated now documented when those APIs (and with it the API docs) are removed. The audience is everyone who is starting the porting work when KF6 is already there for some time. Yes it is manual work. However, since the documentation does not remove stuff that has been removed from the API, it's a thing of adding newer deprecation markers, which seems manageable. Do you disagree? Cheers, Frederik
Re: Porting notes / deprecation docs
Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: > as mentioned earlier Any pointers? :) > I would like to document classes/methods/etc that > are going to be deprecated during KF6 development. Can you help confused-on-first-read people by explaining what "deprecated during KF6 development" is referring to? Deprecated during KF5 development and no longer be available in KF6? Not yet deprecated due to no existing replacement, but with replacement planned in KF6? > For that I scraped up all the deprecation macros from the frameworks and > edited them to be more unified. That sounds like duplication of data, and worse, a manual copy of a certain state, which also needs to be manually maintained to be up-to-date to stay useful. In general I am also curious what audience is targeted by the planned documentation and in which work-flows that documentation should solve which needs, and what other solutions are there which would not satisfy those needs well enough? In general, for API already deprecated now during lifetime of KF5 we are adding porting notes to the very API itself. Which is also the place as API consumer I would be hoping for to get all needed information straight in one go, instead of having to jump to other places, which might even get out of sync or focus of developers (remember that current online docs of api.kde.org also only provide docs for latest version (and even the development one, not just the latest released). And this is a change to what happened in kdelibs4 times, where most deprecation happened in the development branches for what became KDE Frameworks, so there also was no API documentation maintained at the same time. So copying the approach taken for the KDE Frameworks porting notes would not be needed here 1:1 for what I understand. Instead we would need to add documentation for those things which are again deprecated (well, removed rather) during preparation of KF6, where the replacement also only will be in KF6, so no-one can port before. Cheers Friedrich
Re: Porting notes / deprecation docs
On 7/10/21 6:17 PM, Ahmad Samir wrote: On 10/07/2021 18:00, Frederik Schwarzer wrote: Hi, as mentioned earlier, I would like to document classes/methods/etc that are going to be deprecated during KF6 development. For that I scraped up all the deprecation macros from the frameworks and edited them to be more unified. Good work, that must have been a huge task! (82 frameworks ... :)). grep ran a few seconds to give me a 2600 lines text file, which I then had to edit to be more readable, which took me several hours. :) The hard part is still about to come. :) As for the location, I would probably start putting content in the community wiki to a place like https://community.kde.org/Frameworks/KF6_Porting_Notes. Does anyone see a problem with that? Might is be better to write such docs in markdown or restructured text for being better suited for a more modern location? A wiki page is not most friendly way of editing huge technical documents. Personally, I think a markdown file in a git repo would be great, and then it can be "published" to a wiki page or a static web page on one of KDE's web sites. Or, we start with an markdown text file, then after it's fleshed out / polished, put it in the wiki, editing/adding a small section here or there would be easier. (But I do prefer text files, much easier to edit in my usual editor of choice). Yes, I agree. A text file in Git is also better for tracking changes. FWIW, there is supposed to be a KF6 meeting soon[1]. Not sure if we'll start this week or the next one though. I have the Mondays on my calendar now. :)
Re: Porting notes / deprecation docs
On 10/07/2021 18:00, Frederik Schwarzer wrote: Hi, as mentioned earlier, I would like to document classes/methods/etc that are going to be deprecated during KF6 development. For that I scraped up all the deprecation macros from the frameworks and edited them to be more unified. Good work, that must have been a huge task! (82 frameworks ... :)). Now I need some opinions. For once, there is still some stuff in deprecation from KDE4 times. E.g. void setDoScanFile(bool scanFile); from kiowidgets. I looked up a few of them in https://community.kde.org/Frameworks/Porting_Notes but they are not mentioned there. Do you think these need to be mentioned in current porting notes as well or have they been deprecated for long enough to consider them "over with"? I would agree, these ones were probably just forgotten after the kdelibs split, and then couldn't be removed after the first KF5 release so as not to break BIC... etc. (Others who have been around longer will know for sure). As for the location, I would probably start putting content in the community wiki to a place like https://community.kde.org/Frameworks/KF6_Porting_Notes. Does anyone see a problem with that? Might is be better to write such docs in markdown or restructured text for being better suited for a more modern location? A wiki page is not most friendly way of editing huge technical documents. Personally, I think a markdown file in a git repo would be great, and then it can be "published" to a wiki page or a static web page on one of KDE's web sites. Or, we start with an markdown text file, then after it's fleshed out / polished, put it in the wiki, editing/adding a small section here or there would be easier. (But I do prefer text files, much easier to edit in my usual editor of choice). FWIW, there is supposed to be a KF6 meeting soon[1]. Not sure if we'll start this week or the next one though. [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2021-July/118028.html Thanks! Cheers, Frederik -- Ahmad Samir
Porting notes / deprecation docs
Hi, as mentioned earlier, I would like to document classes/methods/etc that are going to be deprecated during KF6 development. For that I scraped up all the deprecation macros from the frameworks and edited them to be more unified. Now I need some opinions. For once, there is still some stuff in deprecation from KDE4 times. E.g. void setDoScanFile(bool scanFile); from kiowidgets. I looked up a few of them in https://community.kde.org/Frameworks/Porting_Notes but they are not mentioned there. Do you think these need to be mentioned in current porting notes as well or have they been deprecated for long enough to consider them "over with"? As for the location, I would probably start putting content in the community wiki to a place like https://community.kde.org/Frameworks/KF6_Porting_Notes. Does anyone see a problem with that? Might is be better to write such docs in markdown or restructured text for being better suited for a more modern location? Thanks! Cheers, Frederik
