tryhardest edited a comment 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-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.
   
   Further we also use;
   WKwebview (Ionic version)
   Whitelist
   SQLite storage
   But you have not suggested those to be depreciated, only to superseed core 
plugins.
   
   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

Reply via email to