How to deal with new features from upstream?

littleredbutton / bigbluebutton-api-php

Unofficial (but better) PHP API for @BigBlueButton

GNU Lesser General Public License v3.0

25 stars 12 forks source link

How to deal with new features from upstream? #144

Closed FelixJacobi closed 6 months ago

FelixJacobi commented 1 year ago

I just tried to merge upstream again, which totally went wrong due to diverging code bases and therefore a lot of conflicts. How should we deal with them in future? Should we still see us as a fork of the original?

As merging upstream is no longer possible from long perspective, some Ideas:

Reimplement everything from upstream from by ourselves.
Just cherry-pick selected commits from upstream and try to fix them.

Both ideas will lead to the fact that we are no longer a real fork.

SamuelWei commented 1 year ago

I agree that by now we are no longer a real fork.

We would have to reimplement everything from upstream by ourselves and closely watch all acitivies in the upstream to not miss important API changes. While reimplementing we might be able to cherry-pick some commits, however I doubt this saves a lot of time compared to implementing it ourselves.

FelixJacobi commented 1 year ago

I checked the comparison of GitHub (see Comparing littleredbutton:master...bigbluebutton:master · littleredbutton/bigbluebutton-api-php) and created issues for each feature, which have been implemented in upstream since our last synchronization. I guess, implementing these would be a good feature set for 5.1.

FelixJacobi commented 6 months ago

With 5.1, it is set. We've implemented new features by ourselves. Therefore, we will no longer merge upstream directly and no longer an up-to-date fork. I would keep the GitHub fork relation for credits to the original authors.