sentry-native

sentry-native copied to clipboard

Description

Each version of sentry-native makes changes to existing function signatures which are not backwardly compatible. This means that when Sentry-native is compiled as a DLL, you cannot use a newer version of the DLL with an existing app. This violates the ABI stability norms for Windows DLLs and means using a shared version of sentry.dll across multiple apps is very difficult.

I am writing this because it's just bitten us and we're now looking at alternatives to solve the problem, none of which are particularly elegant. (Arguably, perhaps we should have realised that the ABI changed between versions and avoided sharing the sentry.dll library between apps in the first place but we didn't -- so here we are.)

My preference for the Windows DLL: any published (exported) function endpoint would have a stable signature and new functionality and changes would be maintained by adding new function endpoints. This does put constraints on your development model, though.

When does the problem happen

• [ ] During build
• [x] During run-time
• [ ] When capturing a hard crash

Environment

• OS: Windows 10 [e.g. Windows 10, 64-bit]
• Compiler: MSVC 19 [e.g. MSVC 19]

We do take API/ABI compatibility seriously, which for native is a bit easier than for other SDKs.

For that we use semver, which allows for breaking changes in minor versions pre 1.0, which we are. We do document those breaking changes. You were going from 0.2.3 to 0.4.9, which is two breaking change versions, and perfectly fine per semver.

The downgrading issue you mentioned in #542 is a different thing though. We reserve the possibility to change internals at any time, and the database is one of those internals.

Worth noting that semver works well in *nix models where every shared library is versioned by filename. But it kinda sucks in the Windows world where most shared libraries are unversioned by default. Perhaps consider changing your sentry.dll file naming scheme if you are going to break back compat at all -- regardless of what semver lets you do 😁. Then at least Windows users won't be bitten in the same way we were.

But there is A-B problem: In which case do you want to update sentry dll independently from the application given the fact that sentry-native distributes exclusively with the application? In most (or all) cases there is no problem to rebuild app during the sentry update.

We have multiple applications with shared DLLs: we'd prefer not to distribute each of those DLLs multiple times. We don't necessarily control the version of the DLL distributed, but Windows version resources (which alas sentry.dll also does not currently have) are used by Windows Installer and other similar technologies to ensure that the latest version would always be installed. But that doesn't help if the DLL does not have backwardly compatible ABI.

in the Windows world where most shared libraries are unversioned by default

To clarify this: Windows DLL versions are mostly not differentiated by filename. WinSxS is one way to solve the problem, and we may use that in future for sentry (this depends on adding version and manifest resources to the sentry DLLs).