Add sdk-version #481
Add sdk-version #481
Conversation
|
Which extensions needs different Sdk version than Platform? In such case there is no abi compatibility guarantee which may lead to (un)expected brokenness. Allowing for messing this up is potential footgun. |
|
Extensions use the App the Extension is for as Runtime and a normal SDK. Because the SDK has not the same Version as the App, you need to specify the version. See this OBS plugin for example. |
|
Ok. The problem I see now is it's backwards incompatible change - all older f-b would fail to properly build new manifest. Maybe it's not worth it if there is easy workaround. |
|
I don't see why that's such a problem that old builder versions cn't build a manifest with the new key. With this argumentation we could also say that we should stop defining a new C++ standard because older versions of g++ can't compile code that uses a newer standard. Introducing YAML manifests were also a mistake, because it couldn't be build by older versions of the builder at this time. If someone uses a older version of flatpak-builder, he uses the old syntax, when someone uses a newer version of flatpak-builder, he uses the new cleaner syntax. If someone wants to switch to an older version, it just a change of 2 lines. |
|
The point is: why bother? Why break backward compat only to fix pure cosmetic issue? I doubt adjusting manifest for this is worth anyone time. |
|
The point here is, that on every point in the manifest you can set a Flatpak ID you also have a separate Key for a version. The SDK is the only point where you need the |
|
I could agree yet not every bug is worth fixing. |
If you want to specify another SDK version than the runtime (what is needed e.g. for extensions) you currently have to use
sdk: name//version. We already have things likeruntime-versionandbase-version, so why not addsdk-version?The code is (of course) tested and works. I hope I didn't miss anything.