Upcoming changes

Hey all -

I have recently joined the project maintainers and would like to introduce myself and share my plans for the project.

I have been using react-native-video in a project for the past year and while it works well, like many of you, I hit a lot of the known (and unknown) bugs. This project is complex and has a crazy amount of technical debt which explains the maintainers burnout and the fact the the project is practically unmaintained at this point.

I have been an open source maintainer for 15 years and have multiple npm modules at the top 500 most downloaded list. However, while I have plenty of open source and JS/TS experience, I sorely lack in native development. I am not going to try and pretend I can perform deep review of native code changes.

I decided to join and help maintain this module because I rely on it for my business and there isn’t any other better solution at this time. Like most of you, I rather just use someone else’s excellent work but fixing what I can myself seems like the only viable option at this point, shortcomings and all. 😃

My immediate plans for this repo are:

• Close all issues that are inactive for more than 6 months - you can always reopen or open a new issue if needed but there is no way to triage 1100+ issues. The longer we keep this list of issues open, the harder it is to get any progress made.
• Convert the project to TS for easier maintenance.
• Update all dependencies to latest version.
• Publish a simple sample app for people to be able to download and run and see it working as well as use as a template for reproducing bugs and confirming fixes. I am going to require most bug reports and fixes to provide a sample app because it is the only way I can review most changes quickly.
• Review as many open PRs as possible and merge them for a new 6.0.0 release. It will be a breaking version because it will take some time to get community feedback that we didn’t break anything that was working before. There will probably be one more 5.x.x release to flush out some simple fixes.

My plan to address my lack of native dev experience is to rely on community reviews and +1s on PRs along with using the test template to reproduce bugs and confirm fixes. If a change’s scope is going to exceed my comfort level, I will publish a -prerelease version first to allow people to test it out and provide feedback.

Ideally, this new injection of energy into the project will motivate old and new contributors to help out but I am no holding my breath based on my experience with projects at this stage in their lifecycle - hence the plan above.

I am always open to ideas, feedback, and plain constructive criticism. Feel free to ping me publicly or privately ([e-mail]).

And if it isn’t obvious, everything on the list above is open for discussion!

[hueniverse]

Decided to publish a 6.0.0 next to make sure nothing breaks for existing code without someone manually upgrading and making sure their code is still working correctly. This will give us more time to fix issues without impacting any 5.2.0 deployments.

[hueniverse]

@freeboub I generally don’t find roadmap discussions helpful. Instead, I prefer to open specific issues for each feature or idea (or architecture changes). This allows the people interested to chime in and keeps the discussion focused. So please feel free to open new issues with well defined topics.