search

apache / cordova

Apache Cordova
https://cordova.apache.org/
615 stars 64 forks source link

Deprecated plugins #185

Open brodycj opened 4 years ago

brodycj commented 4 years ago

A decision was made in Apache JIRA CB-12708 ([1]), back in 2017. At this point we would like to deprecate the following plugins and archive them on GitHub:

Plugins that can be integrated into the affected platforms and archived:

Further discussion is needed on these plugins:

In case we decide to sunset any other plugins within this issue, let's please add them to the appropriate checklist.

Process to follow is documented in [2].

I think it is extremely important that we archive all deprecated plugins in order to avoid the burden of issues and PRs that could come up on GitHub, as I had already said in issue #60.

Additional & related TODO item(s):

[1] https://issues.apache.org/jira/browse/CB-12708 [2] https://github.com/apache/cordova-contribute/blob/master/deprecation.md

brodycj commented 4 years ago

I think the following plugins should be moved into the list for further discussion:

brodycj commented 4 years ago

Some more thoughts on my part:

I would personally downvote integrating plugin functionality into the platforms due to increased complexity and potentially less flexibility. I would make an exception for console which is very basic universal functionality.

The whitelist functionality seems to be a challenging beast since it evidently works differently on Android, iOS, and maybe some other platforms. It would be ideal if we could find a way to abstract it somehow. And the newer iOS WKWebView seems to make this even worse.

I would personally not really mind if the functionality of some of our core plugins would eventually be superseded by some third-party plugins that some members are involved with to a certain extent. For example:

I am fine if we split some of the tasks into separate issues, would like to see the list of deprecated plugins in a pinned issue to help give the user community plenty of warning and opportunity to comment.

tryhardest commented 4 years ago

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.

brodycj commented 4 years ago

Thanks @tryhardest, your comments are definitely valuable. Please accept my apologies for not responding anytime sooner.

Our Apache Cordova maintenance team is mostly if not 100% unpaid volunteers, generally with busy jobs in other companies or busy with freelance work. Volunteers with busy jobs cannot afford to either quit or go part-time, and freelancers like myself cannot afford to put too much work on hold. (I have made some sacrifices on my own in the past and do continue to give as much as I can to help keep maintenance going.) I think a major root cause is that 2 major companies had stopped sponsoring maintenance work.

As a member of Apache Cordova, it makes me extremely unhappy to see things such as:

Definitely a stressful situation for myself and for others involved, including the user community.

I am sure people can understand that the burden of supporting such a large number of old plugins would only add to the unfortunate amount of the existing stress.

I think it would be ideal if we could see more and more plugins would be supported by user community members that we know, that we can keep documented, just like a number of plugins are famously supported by @EddyVerbruggen and SQLite storage is supported by myself.

timbru31 commented 4 years ago

For transparency: We've voted and agreed to resume/revive/un-deprecate the following plugins: