Re: [DISCUSS] Thoughts on Cordova Electron Roadmap
My vote is to go for a single release bumping everything to the latest.
I’m sharing this with the other guys here - I’m sure they will have more
comments.
- George Henne
> On Jan 18, 2024, at 3:50 PM, Bryan Ellis wrote:
>
> Currently the main branch is pinned for next major release 4.0.0 and is quite
> outdated.
>
> Looking at some options.
>
> Release what is currently in the main branch. I believe you can test the
> current main branch by installing nightly. Again, nightly not recommend in
> production. It could be unstable, constantly changing, and has not been
> reviewed or voted on.
> Update to the latest Electron and then prepare a release.
> https://github.com/apache/cordova-electron/pull/263
> Release multiple majors…
>
> Follow up with last two options..
>
> There is a lot of breaking changes between our last release, what’s in our
> main branch, and what’s in the latest release Electron.
>
> To sum up some of the main breaking points:
>
> Our current release version uses Electron is 14.2.9
> Our current main branch, nightly-4.0.0, has already bumped to 19.0.3
>
> 19.0
> Removes of Linux IA32 Binary
> 20.0
> Removes macOS 10.11 (El Capitan) and macOS 10.12 (Sierra)
> 23.0
> Removes Windows 7, Windows 8, and Windows 8.1
> 25.0
> Deprecated:
> protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol - This
> is something we used to support custom scheme but there is a replacement.
> 27.0
> Removes macOS 10.13 (High Sierra) and macOS 10.14 (Mojave)
>
> There is plenty of other breaking changes (deprecation), but in terms of what
> APIs Cordova uses, its not an issue. You would need to investigate and
> resolve on your end if your using any of the APIs they deprecated.
>
> Full Breaking Changes: https://www.electronjs.org/docs/latest/breaking-changes
>
> I am leaning more towards a single release and just bump to the latest. The
> main branch already contains the feature to allow custom Electron versions
> . The above PR #263
> should support the use of older Electron versions, if people wish to use an
> older versions to build for older OS. The only downside I foresee would come
> from plugins if they choose to use a deprecated or new API.
>
> Also does anyone develop/maintain plugins made for Cordova Electron? Using
> the plugin ecosystem that was introduced in version 2.0.0?
>
> There was a bad pattern that was added accidentally. It doubled wrap the
> arguments that were passed to the native side. This multidimensional array is
> not needed and should be resolved. As the fix would be breaking change I
> just wanted to hear what others think.
>
> I did an npmjs search for the keyword cordova-electron and it yielded 37
> modules.
>
> Not all modules maybe be valid.
>
> Some didn’t appear to have a source folder for electron. 26 of them appear to
> be some variations of one plugin.
>
> Since the number of plugins are small, and possibly still maintained, it
> might be best to make this change now.
>
> Let me know if anyone has thoughts:
>
> -> Merge in PR #263
> -> Remove the accidental multidimensional array from plugin.
> -> Include an upgrade for all the other dependencies
> -> Release a single release with Electron bumped to its latest 28.x
>
>
Re: [DISCUSS] Thoughts on Cordova Electron Roadmap
> Remove the accidental multidimensional array from plugin
+1 for this... I think this might become a source of problems later...
and the longer we wait the more difficult it might be to change.
> Release a single release with Electron bumped to its latest 28.x
I'd favour this but I don't use electron in any of my projects so I'll
vote +0 (indifferent). Browser engines goes through fast update cycle,
they are large and complex and as a result, security updates are
published very frequently. Electron however, unlike other platforms
don't have access to a independent-upgrading browser runtime like say,
Android does. This makes keeping up with electron updates rather
important since they will include being built against updated, possibly
more secure browser runtimes. So unless if there is any rejection, I
think we should update electron as quickly as we can.
On 2024-01-18 16:50, Bryan Ellis wrote:
Currently the main branch is pinned for next major release 4.0.0 and is quite
outdated.
Looking at some options.
Release what is currently in the main branch. I believe you can test the
current main branch by installing nightly. Again, nightly not recommend in
production. It could be unstable, constantly changing, and has not been
reviewed or voted on.
Update to the latest Electron and then prepare a release.
https://github.com/apache/cordova-electron/pull/263
Release multiple majors…
Follow up with last two options..
There is a lot of breaking changes between our last release, what’s in our main
branch, and what’s in the latest release Electron.
To sum up some of the main breaking points:
Our current release version uses Electron is 14.2.9
Our current main branch, nightly-4.0.0, has already bumped to 19.0.3
19.0
Removes of Linux IA32 Binary
20.0
Removes macOS 10.11 (El Capitan) and macOS 10.12 (Sierra)
23.0
Removes Windows 7, Windows 8, and Windows 8.1
25.0
Deprecated:
protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol - This is
something we used to support custom scheme but there is a replacement.
27.0
Removes macOS 10.13 (High Sierra) and macOS 10.14 (Mojave)
There is plenty of other breaking changes (deprecation), but in terms of what
APIs Cordova uses, its not an issue. You would need to investigate and resolve
on your end if your using any of the APIs they deprecated.
Full Breaking Changes: https://www.electronjs.org/docs/latest/breaking-changes
I am leaning more towards a single release and just bump to the latest. The main
branch already contains the feature to allow custom Electron versions
. The above PR #263 should
support the use of older Electron versions, if people wish to use an older versions
to build for older OS. The only downside I foresee would come from plugins if they
choose to use a deprecated or new API.
Also does anyone develop/maintain plugins made for Cordova Electron? Using the
plugin ecosystem that was introduced in version 2.0.0?
There was a bad pattern that was added accidentally. It doubled wrap the
arguments that were passed to the native side. This multidimensional array is
not needed and should be resolved. As the fix would be breaking change I just
wanted to hear what others think.
I did an npmjs search for the keyword cordova-electron and it yielded 37
modules.
Not all modules maybe be valid.
Some didn’t appear to have a source folder for electron. 26 of them appear to
be some variations of one plugin.
Since the number of plugins are small, and possibly still maintained, it might
be best to make this change now.
Let me know if anyone has thoughts:
-> Merge in PR #263
-> Remove the accidental multidimensional array from plugin.
-> Include an upgrade for all the other dependencies
-> Release a single release with Electron bumped to its latest 28.x
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
[DISCUSS] Thoughts on Cordova Electron Roadmap
Currently the main branch is pinned for next major release 4.0.0 and is quite
outdated.
Looking at some options.
Release what is currently in the main branch. I believe you can test the
current main branch by installing nightly. Again, nightly not recommend in
production. It could be unstable, constantly changing, and has not been
reviewed or voted on.
Update to the latest Electron and then prepare a release.
https://github.com/apache/cordova-electron/pull/263
Release multiple majors…
Follow up with last two options..
There is a lot of breaking changes between our last release, what’s in our main
branch, and what’s in the latest release Electron.
To sum up some of the main breaking points:
Our current release version uses Electron is 14.2.9
Our current main branch, nightly-4.0.0, has already bumped to 19.0.3
19.0
Removes of Linux IA32 Binary
20.0
Removes macOS 10.11 (El Capitan) and macOS 10.12 (Sierra)
23.0
Removes Windows 7, Windows 8, and Windows 8.1
25.0
Deprecated:
protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol - This is
something we used to support custom scheme but there is a replacement.
27.0
Removes macOS 10.13 (High Sierra) and macOS 10.14 (Mojave)
There is plenty of other breaking changes (deprecation), but in terms of what
APIs Cordova uses, its not an issue. You would need to investigate and resolve
on your end if your using any of the APIs they deprecated.
Full Breaking Changes: https://www.electronjs.org/docs/latest/breaking-changes
I am leaning more towards a single release and just bump to the latest. The
main branch already contains the feature to allow custom Electron versions
. The above PR #263 should
support the use of older Electron versions, if people wish to use an older
versions to build for older OS. The only downside I foresee would come from
plugins if they choose to use a deprecated or new API.
Also does anyone develop/maintain plugins made for Cordova Electron? Using the
plugin ecosystem that was introduced in version 2.0.0?
There was a bad pattern that was added accidentally. It doubled wrap the
arguments that were passed to the native side. This multidimensional array is
not needed and should be resolved. As the fix would be breaking change I just
wanted to hear what others think.
I did an npmjs search for the keyword cordova-electron and it yielded 37
modules.
Not all modules maybe be valid.
Some didn’t appear to have a source folder for electron. 26 of them appear to
be some variations of one plugin.
Since the number of plugins are small, and possibly still maintained, it might
be best to make this change now.
Let me know if anyone has thoughts:
-> Merge in PR #263
-> Remove the accidental multidimensional array from plugin.
-> Include an upgrade for all the other dependencies
-> Release a single release with Electron bumped to its latest 28.x
