[Enhancement] Starting a new experimental branch

@bsutton :

I agree that starting a new experimental branch is probably the best trade-off/compromise that we can find together. I am going to rename the dev branch as experimental.

It will be possible to publish this branch as “5.0.0-experimental.1” if @hyochan agrees (he is the project leader).

The major problem that I see, is that this experimental branch looks terribly like a fork. I am going to release next week a new Flutter Sound version with new codecs. Those codecs will be missing in the experimental branch. In the other direction, the experimental branch will probably fix some problems that we actually have in the master branch.

And more the time will pass, more we will diverge. This is what is called a fork. And a fork is not something that I like very much. Specially when we are 3 developers (@salvatore373 , you and me) and we want to work on 3 different forks. @salvatore373 told me that he wants that I publish its branch as BETA, and just wait for a feedback from our users. If I don’t do that, he will publish his own fork. I tried to explain him that we must work together to improve Flutter Sound and not split our force. Actually you are requesting exactly the same thing : publish a new fork called “experimental”.

I see 3 forks when we are 3 developers as a failure of my anarchist/libertarian ideas. I believe in anarchy. I really think that it is possible to develop great things without a boss to drive us. I was an activist in a political anarchist movement. We was just a few hundreds. Nothing. We was much too small to count in the political arena. But because we had no leaders, we always argue together, and every two years we had a new split in two new movements. This was failures. But I still continue to believe in anarchy. I believe that we can combine our forces without any leaders.

What can we do to work together instead of forking ?

[bsutton]

Just thought it might be worth highlighting what our user will get if we move forward with the 5.0 branch.

• SoundPlayerUI widget
• SoundRecorderUI widget
• RecordingPlaybackController widget (pairs a recording and player widget).
• QuickPlay for short audio playback.
• consistent api (e.g. consistent usage of Tracks, naming conventions…)
• Fixes for jank when starting a player
• Fixes for a no. of crashes due to race conditions during initialisation
• Support for app pause/resume
• Stability of the api as apposed to the constant changes that are occurring now.
• Fixes for Future handling (causing more jank).
• Improved api documentation.
• Improved streaming model for duration/db tracking
• Cleaner public api - I’ve work to hide any internal methods.
• cleaner permission model.
• a path to a cleaner codec support model

Without 5.0 we loose most of the above and they will be a long time coming.

[bsutton]

@Larpoux whether we fork now or not is in your hands.

The simplest way to stop the fork is to stop all new features in the 4.x branch.

We put 4.x into maintenance only mode.

If users want the new features of the 5.x branch then they need move to 5.x.

This will have the following benefits:

1. A stable branch in 4.x
2. This will generated the user feedback that we need to resolve any issues.
3. free up additional resources to test 5.x

If you continue adding new features to 4.x then we will have a fork. If you stop adding new features to 4.x then we won’t end up with a fork.

Here is what I believe will give the best long term result for users of flutter sound.

1. cease all new development on 4.x - bug fixes only
2. develop a plugin architecture for adding new codes ( I will raise an issue for this).
3. start writing unit test for 5.x. This will overcome your concerns that 5.x is not reliable and help create a stable build going forward.
4. push out a alpha of 5.x asking for user feedback.

The project really needs both of us working together. Its large and complex and really needs multiple skill sets.

The 5.x branch is needed as it fixes some really fundamental issues. The above plan gives users stability and moves the project forward.

Anarchy only works if we listen to each other.

I’ve heard that you need stable low risk updates. I’m saying that we need to re-architecture flutter sound if we want it to be stable with the new features we need to support.

The above plan give us both.

Its up to you now. You need to make a management decision 😃

Do we fork or not?