Bindings currently ship every Selenium Manager binary in the primary binding package. That increases package size and duplicates storage/downloads for binaries that will not run on the installing platform. This concern becomes more important as #17586 adds additional Selenium Manager platform binaries. .NET has its own ecosystem-specific solution for native runtime assets, so this may already be handled there or tracked separately.
This follows up on #13021 with a different proposed direction: release Selenium Manager as its own package, with platform/architecture-specific variants where the package ecosystem supports them. The Selenium binding package should depend on or resolve the appropriate Selenium Manager package instead of bundling all binaries directly.
Normal Selenium installs should continue to work as they do today. Users should not need to manually choose a Selenium Manager package for common supported platforms, and existing overrides like SE_MANAGER_PATH should continue to work.
Bindings currently ship every Selenium Manager binary in the primary binding package. That increases package size and duplicates storage/downloads for binaries that will not run on the installing platform. This concern becomes more important as #17586 adds additional Selenium Manager platform binaries. .NET has its own ecosystem-specific solution for native runtime assets, so this may already be handled there or tracked separately.
This follows up on #13021 with a different proposed direction: release Selenium Manager as its own package, with platform/architecture-specific variants where the package ecosystem supports them. The Selenium binding package should depend on or resolve the appropriate Selenium Manager package instead of bundling all binaries directly.
Normal Selenium installs should continue to work as they do today. Users should not need to manually choose a Selenium Manager package for common supported platforms, and existing overrides like
SE_MANAGER_PATHshould continue to work.