tryhardest commented on issue #185: Deprecated plugins URL: https://github.com/apache/cordova/issues/185#issuecomment-574777183 To be clear I presume you are only suggesting sunsetting when newer versions of plugins are available aka close-to drop in replacement plugins? Often new webAPIs that have core plugin functionality fully supported but cannot alone do the extended things some of those listed plugins can. At least not without months of work all told, or a huge amount of additional build out and refactor (maybe enough to kill businesses) which could honestly accompany this decision on next Cordova upgrade cycle, when these would all possibly become unusable. If for some reason (there often are) projects forced into an upgrade cycle and they find half their app no longer functions. The whole model of Cordova was and is plugin extendability. Certainly hasn't been easy doing so with the complexity of version control, maintainers falling off, conflicts, etc. However, these are all critical plugins for many people who spent massive amounts of time and resources integrating them fully, and as mentioned the extended functionality and use cases in many of the listed plugins is critical to apps functioning correctly. Wouldn't it make more sense seeing as Capacitor functions also on Cordova plugins, to promote upgrading and ongoing development of them by respective maintainers? Or suggesting the plugins reach out for some help and make the appropriate changes to be current? Users always have the option to opt for webAPIs anyway, so why not take that approach without actively promoting the depreciation of so many complex plugins. the depreciation suggestion of these; apache/cordova-plugin-contacts apache/cordova-plugin-device-motion apache/cordova-plugin-device-orientation apache/cordova-plugin-file-transfer apache/cordova-plugin-media apache/cordova-plugin-file-transfer apache/cordova-plugin-media apache/cordova-plugin-media-capture apache/cordova-plugin-camera apache/cordova-plugin-file All of which we use, seems like untold headaches. For a small team that could potentially kill us. Took long enough to get all the plugins working correctly. We also additionally use Splashscreen Whitelist but personally we have no issue for those to be integrated, I've always felt that they should be. So I guess I am trying to get a better understanding of how this depreciation is being approached without potentially devistating consequences for thousands of projects moving fwd. Maybe my understanding of stopping active support, development and matenaince on them is elevated due to knowing there is an enevitable dead end with this approach whereby the continuing advancement of the platform will eventually collide with their use at all, rending all the code surrounding each to be unusable. I know (and am grateful) that you maintain many plugins and for your work on Cordova proper. I personally feel if we all took one or two of them under our wings (with webAPI optionality) it's a better approach. Aren't plugin maintainers the ones to decide if they want to continue updating and maintenance on a plugin anyway? In summary; sorry I'm not fully understanding your posts. I am understanding this as either devastating ultimately to our project moving fwd or enough new work that it will destroy our small team because we depend on so much of what you have mentioned. Thanks you.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cordova.apache.org For additional commands, e-mail: commits-h...@cordova.apache.org
