Blow WindowPlugins.dll to separate plugin DLLs (2 Viewers)

[azzuro]

But after this change we also have possibility to provide these plugins as MPEI package(s).

if exernal plugin need to use internal as reference, what do you think to only update the plugin as my 2nd proposition ?

 

[azzuro]

I agree 100%. It will be possible to install/remove only the plugins that the user wants, but we need to ensure that we have appropriate dependencies in place, so that if a plugin requires 'My Videos', it will either fail the dependency check or offer to install My Videos using MPEI. What the plugin must absolutely NOT do is provide a My Videos binary in its own installer.

i think, we don't set it, as deletable, if i'm wrong, say me!
i prefer have all plugins installed, but desactivated in config for start with MP.
Q : all dlls available in plugins folder, start with MP if are desactivated ?

 

[mm1352000]

At least MPTVSeries needs to be recompiled against this but it requires only fixing of references & imports.

Hmmm, recompiled...
I'm not a plugin dev so maybe this comment should just be ignored, but I have the impression that every release we seem to do something that requires plugin changes or recompilation to maintain compatibility. It feels like this is happening more frequently than in the past, and not just because of the more frequent releases.

In the past we actively tried to avoid breaking changes or planned them in such a way that such changes were in a single release, then we would try to avoid/delay new breaking changes for the next release or two. The train process currently says any change that is ready can be merged.

I informally propose that the train process could benefit by having some acceptance/merging criterion/criteria added to avoid this situation of breaking changes every release. Could we say something like: breaking plugin changes only allowed once every second release?

Again: I'm obviously not a plugin dev. Just have the feeling that the less active or busy or otherwise occupied plugin developers that don't closely follow our internal release and testing process... I'm concerned they would get frustrated with every 3 months or so having another reason to have to recompile or release a new version outside (on top of) their own normal release processes. These are exactly the people that are unlikely to say anything to the team directly...

 

[seco]

At least MPTVSeries needs to be recompiled against this but it requires only fixing of references & imports.

Hmmm, recompiled...
I'm not a plugin dev so maybe this comment should just be ignored, but I have the impression that every release we seem to do something that requires plugin changes or recompilation to maintain compatibility. It feels like this is happening more frequently in the past, and not just because of the more frequent releases.

In the past we actively tried to avoid breaking changes or planned them in such a way that such changes were in a single release, then we would try to avoid/delay new breaking changes for the releases or two. The train process currently says any change that is ready can be merged.

I informally propose that the train process could benefit by having some acceptance/merging criterion/criteria added to avoid this situation of breaking changes every release. Could we say something like: breaking plugin changes only allowed once every second release?

Again: I'm obviously not a plugin dev. Just have the feeling that the less active or busy or otherwise occupied plugin developers that don't closely follow our internal release and testing process... I'm concerned they would get frustrated with every 3 months or so having another reason to have to recompile or release a new version outside (on top of) their own normal release processes. These are exactly the people that are unlikely to say anything to the team directly...

This was already discussed in internal forums where following statements were made
1) Plugin compatibility bump needs to be done and it will break plugins. (I have stated this many times in various places, this thread, Jira, internal forums)
2) In the past breaking changes were not allowed in subsequent releases (infinite.loop)

 

[mm1352000]

@seco
Please don't get me wrong. I'm not making any judgement about whether this change should be included. I usually try to keep my nose out of such discussions. I just happened to be browsing this thread and saw your comment about recompiling. Again, please feel free to ignore my comment if it is off topic.

 

[elliottmc]

Did we break plugin compatibility in 1.6.0 ?

I guess at least with the releases being more frequent, any plugin that is compatible with 1.6.0 is being actively developed so there should in principle not be a problem with getting an updated version.

I guess overall, the question is whether we as a team will benefit more from splitting windowsplugins to separate files. If we will (in terms of maintenance of code, stability, etc.) then I think we should just bite the bullet and get it done, as long as the code is properly tested and reviewed.

If there aren't enough gains, we could delay for a release, but then there is the risk that some plugins will become unsupported and then not be updated.

I will have to be guided by developers in terms of the benefits versus the inconvenience of a little tweak to plugins.

 

[seco]

@seco
Please don't get me wrong. I'm not making any judgement about whether this change should be included. I usually try to keep my nose out of such discussions. I just happened to be browsing this thread and saw your comment about recompiling. Again, please feel free to ignore my comment if it is off topic.

No, I did not get you wrong I was also suggesting that we should maybe postpone this to 1.8.0 but then again we might encounter merge hell so the sooner we get this out for testing and released the better. But it's not my decision.

1.6.0 broke plugins also.

 

[Edalex]

Did we break plugin compatibility in 1.6.0 ?

Yes, in the worst way since introducing compatibility management in 1.2.0. all because of net 4
Many devs can't make single plugin dll compatible with both 1.5.0 and 1.6.0 anymore.

 

[edterbak]

Many devs can't make single plugin dll compatible with both 1.5.0 and 1.6.0 anymore.

ouch.. do they need help?

 

[HTPCSourcer]

Many devs can't make single plugin dll compatible with both 1.5.0 and 1.6.0 anymore.

Would there be a reason to not have users upgrade to 1.6 anyway? It's not uncommon to see software not supporting older versions anymore, especially if it's free of charge like MediaPortal.