search

dyne / frei0r

A large collection of free and portable video plugins
https://frei0r.dyne.org/
GNU General Public License v2.0
419 stars 91 forks source link

recent renaming commits breaking compatibility #171

Closed ddennedy closed 1 year ago

ddennedy commented 1 year ago

Now, anything referencing the plugins by their name including code, project files, and scripts will no longer load the expected plugin. I am referring to commits: 7228e0fb4fb9d99a207e651529fc9a990c771c53 ad4cbc890bbdedb227eb28af1f5e09976847f280 dbb348630c08a55f7705df83662bd7fe0f4c6275 929afe1e4425b92be448ed31a8860c61d4544a10

Is a major compatibility break really improvement - just to have names that you prefer? Now, I need to add a compatibility shim in MLT, but I suspect others will complain too.

jaromil commented 1 year ago

Dear Dan, yes I am aware of the side effects of renaming and planned to tag a breaking change with major release series 3 to mark it. But before taking a decision I wanted to wait for reactions and discussion as well find the time to explain the reason for this naming scheme.

Names are the only way so far to understand if a plugin belongs to a common codebase with share code, something happening in a small number of cases. To create a link to the shared codebase is useful in two upcoming cases:

  1. renaming of function declarations to be unique at runtime, necessary to build a libfrei0r.a static lib and a wasm executable
  2. presence of duplicate filters depending from different implementations but aiming at providing the same general transformation

I am happy if we can discuss, we can also have a voice call if you prefer. Wish you a great weekend!

ddennedy commented 1 year ago

Thanks for explaining the rationale; I did not know about the plans. I will implement the compatibility code in MLT.