Updated workflows for sm1.12 checking.#25
Conversation
|
Sorry — I forgot that the PRs will need to be modified to accommodate the changes introduced in #22. |
| sm_branch: "1.11-dev" | ||
| spcomp_version: "1.11.x" | ||
|
|
||
| - sm_version: "1.12" |
There was a problem hiding this comment.
I don't think sm_version is a key / value that's used anywhere in the workflow. I think you wanted a corresponding meta_branch?
| sm_branch: "1.11-dev" | ||
| spcomp_version: "1.11.x" | ||
|
|
||
| - sm_version: "1.12" |
There was a problem hiding this comment.
Ah right, so 1.11 is now considered oldstable — I don't think there's any compelling reason to keep 1.11 now, and the release steps weren't built with multiple SM versions in mind (there's only release archives for Linux and Windows, both containing 32-bit and 64-bit extension builds).
This PR may be effectively redundant with #22, but we'll see once that gets a final once-over and merged.
|
|
||
| - sm_version: "1.12" | ||
| sm_branch: "1.12-dev" | ||
| spcomp_version: "1.12.x" |
There was a problem hiding this comment.
If I recall correctly spcomp 1.12 has flawed codegen due to the major refactoring work done on sourcepawn's side, so I'd probably opt to keep this at 1.11.x.
SourceMod plugin files are generally architecture-independent and there currently aren't any changes in plugin-space that improve support of 64-bit memory.
There was a problem hiding this comment.
sm1.12-7170 seems to resolved some flawed codegen problem I remembered, which is the version I have been using until now.
As for the improvement of memory functionality you are right, nothing bright so it is a reason to stay 1.11.x. If this is not necessary then I agree that this pr can be closed.
2 participants
No description provided.