Show required dependency version range

[maraf]

Packages have dependency on GitExtensions.Plugins version >=3.1 && < 3.2.
We should display this in UI.

Currently we are not checking required version on the dependency, as discussed in maraf/GitExtensions.PluginManager#36.
If we change our mind, may be this issue will not be needed.

[mast-eu]

This one sounds a bit strange to me.
If the minimum version is not met, than I would expect that the plugin is not even visualized in the PM, because I cannot install it anyhow.
And defining a maximum version seems like planned obsolescence.
I'm not aware of any software using this, but maybe it's just due to my limited knowledge ...Can you provide an example where this system is used?

[maraf]

If the minimum version is not met, than I would expect that the plugin is not even visualized in the PM, because I cannot install it anyhow.

This is correct and I agree, but after some discussion with @RussKie we have (I think temporarily) disabled it. See the referenced issue maraf/GitExtensions.PluginManager#36.

And defining a maximum version seems like planned obsolescence.

I'm going to borrow Mads's word from https://devblogs.microsoft.com/visualstudio/visual-studio-extensions-and-version-ranges-demystified/.

There is no way of knowing that an extension will work in all future versions of Visual Studio. It probably won’t and will eventually cause a runtime error in that future version.

Example:

• I built BundleBackuper-v2.* for GE-v3.0.0.
• When I installed GE-v3.1.0, BundleBackuper stopped working, because something changed.

So PM should never allow installation of BundleBackuper-v2.* in >= GE-v3.1.0.
In addition, event GE should not load plugin, which is not supported for that version.

[mast-eu]

Thank you for pointing me to maraf/PluginManager#36.
I agree with the conclusion from there. Let's start with a minimum viable product (i.e. without automatic version checking) and decide later on whether and how we need to add it. By the time we get back to this we will also have more practical experience and, hopefully, also some user feedback.

At the moment there are only GE members maintaining plugins. And we will be well aware of any incompatible API changes in future GE releases and be able to prepare updated packages in time.
Therefore I'm not too concerned about checking and/or visualizing the dependency range.

Do you agree?

[mast-eu]

See also gitextensions/gitextensions.extensibility#2 for further thoughts about versioning and version ranges.

[maraf]

Do you agree?

Sure, it's not a must for the first release.

Why not move all interfaces and classes related to the plugin abstract layer to its own project?
All projects will dependent on interfaces (GE, SomePlugin...)

[RussKie]

This is what https://github.com/gitextensions/gitextensions.extensibility is for.
But we haven't formally proceeded with it yet.

Is something blocking file transfer? Empty repository.

[mast-eu]

The repo is not empty, but almost. At least it doesn't contain much code (only PowerShell) if that's what you mean.

I don't quite understand what this project is for. I thought there were interfaces.