How to handle Electron Version selection in the future?

[softworkz]

IMO, this is getting too complicated. It would be much easier and better when the adaption would happen dynamically during runtime - depending on the Electron version that is selected in the project properities.

Please see the discussion above and the examples I'm giving about how MS/Xamarin have been doing this for Android API changes for a long time already without shipping dozens of different versions.

I definitely understand this approach but was thinking to adopt Electron release approach thats why I was asking about incremental versions - in case there is a known bug for a specific release lets say for 36.0.0 then 36.0.1 would be released. While what you are proposing sounds great how complicated would it be to implement?

So for example lets say in version 37 a method takes an object of specific type as an input while in 38 it takes a string, is that easy to implement?
Some methods and events are added while others are dropped.

As for versioning already found my answer on Google - yes it is possible to publish lesser versions to Nuget.

Don't get me wrong what you proposing sounds like a proper sophisticated solution but is not something I am familiar with and would require considerably more time investment upfront than I can spare. I will leave it with you.

Originally posted by @agracio in #872

[softworkz]

I'm creating this new issue, because we've gotten quite a bit off-topic in the Taking it to the Next Level! issue.

Why do I think that a freely selectable Electron version is better?

(than having specific Electron.NET packages for each Electron version)

1. The approach has failed already

Because "having specific Electron.NET packages for each Electron version" - that is/was the current approach.

The decision to do so has surely been made for good reasons. And surely also in good faith, assuming to continuously publish new versions for new Electron versions. Eventually, this hasn't happened -. or rather ended at some point.
No matter why - it's open-source and free and there are no obligations to deliver any updates. As simple as that.

But unfortunately, in turn, the lack of updates has moved the project totally off-the-line.
As of now, it has completely disqualified itself for any kind of professional use.
It's future is uncertain, and even when there was a single update now, chances exist that it would stall once again afterwards.

2. Electron Updates are Security Relevant

A hard-coded version like 23.2.0 is another instant-disqualifying factor as well. You need to be able to use versions which have security fixes included.

3. API Changes?`

We have established already that Electron API changes are largely minimal and do not even bite most of the time.

Is this a solid reason to force users of Electron.NET onto a certain Electron version all the time until Electron.NET publishes a new version where those small API differences are addressed?

Think about - what would YOU want as a developer? Free version choice with a small risk that something breaks or being dependent on some open source developers finding the time to release a new version? (which might never happen at all)

4. API Versions

Another element has been forgotten a bit in this discussion as well: The primary reasons for changing or updating Electron are most of the time not the Electron features at all - but the features of the newer Chromium versions. That's why people want to update Electron most of the time, and that's why 23 is not an acceptable choice these days, even when don't need any newer Electron features.

[softworkz]

I am not saying that one solution is better than other and your idea does sound like it would be a great one with definitions loading dynamically, my point was that I am not ready to take on a such complex job hopefully owners can give you a hand.

That's what I've been alluding to in the other conversation, where you said you "completely disagree with the approach":

But this approach just accommodates for the fact that

• the owners have no time
• I have no time

for doing that many releases for each Electron version.
You can disagree as long as you want - but it's not gonna happen unless YOU do it or another volunteer comes around.
What I'm suggesting (how I've implemented it), is meant to give the project a future even without intensive work by me or by the owners.

Either that - or nothing - or YOU do it. That's the reality at the moment.

[agracio]

I disagree about a couple of things:

2. Electron only supports 3 latest releases so assuming that there are security issues with Electron itself it needs to be upgraded.
   If ElectronNET package for that release (example 36.0.0) has a security issue then an updated version 36.0.1 can be released.
3. API changes are minimal to a few methods/events between each major version but are very significant if we compare major versions that are far apart.
4. There is another reason to upgrade to newer Electron version - and that is support. As I mentioned earlier Electron only supports 3 latest releases, raising an issue for any other version gets an instant reply 'this version is no longer supported try to replicate this bug on supported version'

But this approach just accommodates for the fact that

• the owners have no time
• I have no time

This can be said about any repo - if it is not maintained it becomes obsolete.

You were proposing a different solution where depending on Electron version chosen different API would be loaded - if you have no time then who is going to develop this solution.

[softworkz]

While what you are proposing sounds great how complicated would it be to implement?

So for example lets say in version 37 a method takes an object of specific type as an input while in 38 it takes a string, is that easy to implement? Some methods and events are added while others are dropped.

Assuming you would volunteer to maintain this, I would get all things set up and give you instructions in a way that you'd only need to monitor the API diffs and implemented the changes according to the given patterns and instructions. And you can also ping me for help when in doubt.

So, when you really like to do it, you don't need to worry about the hard parts - I would get you there, that's no problem.

[agracio]

Assuming you would volunteer to maintain this, I would get all things set up and give you instructions in a way that you'd only need to monitor the API diffs and implemented the changes according to the given patterns and instructions. And you can also ping me for help when in doubt.

But you would have to implement the initial API changes for a current Electron version 36, 37 or 38 and there are alot of them. Unless I misunderstood and you are proposing to not implement any API changes.

[softworkz]

But you would have to implement the initial API changes for a current Electron version 36, 37 or 38 and there are alot of them. Unless I misunderstood and you are proposing to not implement any API changes.

I would lay the groundwork that allows you to implement the API changes (similar to how Xamarin handles Android API changes).

[agracio]

Could you elaborate with examples on how Xamarin handles changes, besides it still means maintaining each Electron release API changes just in a different way. After each change a new package needs to be published to Nuget.

Just finished my Electron 38 release so will look at this topic again tomorrow, good night 😴

[softworkz]

Here are some examples of what I'm talking about:

“Introduced in API X” annotations

https://learn.microsoft.com/en-us/dotnet/api/android.service.credentials.action

Deprecations mapped to .NET [Obsolete]

https://learn.microsoft.com/fr-fr/dotnet/api/android.provider.mediastore.video.videocolumns.author

Platform/version awareness via [SupportedOSPlatform]

https://learn.microsoft.com/en-us/dotnet/api/system.runtime.versioning.supportedosplatformattribute
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.versioning.unsupportedosplatformattribute

How it works on build

We (=I) create an Analyzer that is run on build (the user's build of their Electron.NET solution) and that is checking whether any APIs are used which are not available in the chosen Electron version.

That's basically how it works. Deprecations create a warning and hard incompatibilities create an error.

[agracio]

I was just about to add another thing, both .NET and Node.js solutions need to implement API changes for each version of Electron.
API changes also have to apply to src\ElectronNET.Host\api\*.ts

[softworkz]

The above is the declarative side. For the implementation side, the recipes are:

New parameter added in new API version

We implement the parameter on both sides (C# and js). There are attributes for parameters as well.
An added param is down-compatible, because it will just be ignored at the js side

Parameter removed in new API version

We do nothing except add an attribute. Reason: see above

Entirely incompatible change

Different parameter type, different parameter order, totally diferent params, etc.

We add new methods, both on the C# and js side, with a name like:

apifunctiion37(param, param, etc.)

The new one gets decorated as available from 37 and the old one as available until 36.
This case is rare, but it can happen. MS/Xamarin to it the same way.

[softworkz]

Version Statics

In some cases, it might also be needed to adjust the bridging code (between C# and js) depending on the Electron version.

For those cases, we will also inject a global static variable (both, C# and js side) based on which you can vary the implementation when necessary.

[agracio]

I am not following - let say we compare API of version 23 to 30, we find new methods, events also removed methods and events, changed method signatures etc. Those changes need to be implemented on both sides.

Next we compare 30 to 36 - again the same happens and we are talking about a significant amount of changes in both cases. When we moving from version to version those cases are not rare and are very common when jumping multiple versions. I just dont see how your approach of adding extra methods, extra decorations etc is better.

This very much looks like a nan approach that has code riddled with 'if/else' only in this case its new method names and pretty decorations instead of if/else but still will be a complete mess is we look across 15 versions from 23 to 38 and it will just keep growing with every new version.

Besides this approach still means that a new package needs to be published to Nuget with every new version of Electron so not sure what are the gains.

[softworkz]

I am not following - let say we compare API of version 23 to 30, we find new methods, events also removed methods and events

You need to go version by version.

23 to 24
24 to 25
25 to 26
etc.

Besides this approach still means that a new package needs to be published to Nuget with every new version of Electron so not sure what are the gains.

The gain is that when no new package is published, you can still update to a newer Electron without being restricted to the latest version that Electron.NET is supporting.
You have the risk of incompatibility, but you can look up the changes or just try out whether you're affected.
Generally, it's pretty unlikely that you are affected and that allows you to update to a newer Electron without depending on Electron.NET. And when there's an API change that bites you, you can still submit a PR to Electron.NET to get it fixed.

That's the gain - and it's huge.

Currently: Forced to 23.2
Future: Never locked anymore

[softworkz]

And even when Electron.NET would be entirely dead and wouldn't merge your PR - you can still use ElectronHostHook for implementing a new or changed API yourself and use that instead of the shipped and incompatible one.