SFML
SFML copied to clipboard
SFML
Suggestion: finish 2.6.0
As per this issue: https://github.com/SFML/SFML/issues/1778, the last release was a long time ago and the 5-6 open stories have been there for a while now. Wouldn't it be better to release 2.6.0 and fix whatever bugs appear in 2.6.1, when more users start to use it?
https://github.com/SFML/SFML/issues/2066 needs to get fixed but otherwise I think we're ready to start the 2.6.0 release process.
EDIT: #2066 was fixed by #2073
As per this issue: #1778, the last release was a long time ago and the 5-6 open stories have been there for a while now. Wouldn't it be better to release 2.6.0 and fix whatever bugs appear in 2.6.1, when more users start to use it?
As far as the release of 2.6.0 is concerned one of the big features from the roadmap (#1235) is still under development, meaning review and testing is still yet to come. But yeah, the community is eager for a new release, it has been a long time and we'd all love to see one. The longer 2.6.0 takes to come, the even longer before 3.0.0 will ever see the light of day.
No updates, sadly. The SFML team are still waiting on scancodes to get merged before considering releasing 2.6.0 which is planned to be the last SFML 2 release. There hasn't been much movement on that PR in the last few months so it's hard to say when it will get done.
I ended up forking SFML and used a patched scancode branch with the duplicate keys fix applied from another PR (here).
I have 3 working applications that use both keys and scancodes here: https://github.com/dgcor/Columns https://github.com/dgcor/DGEngine https://github.com/dgcor/Diabolika
They're configured using json so it's easy to test the many keys without recompiling the code:
https://github.com/dgcor/Columns/blob/master/gamefilesc/ui/gameInputEvents.json https://github.com/dgcor/Diabolika/blob/master/gamefilesdiaex/ui/gameInputEvents.json
The windows implementation seems to be solid. Linux works, but I sometimes run into small bugs (scancode stopped responding once).
Since this is the main feature holding back the release, and it's been a few months and no major change happened in the 2.6 branch, I'm pushing again to see if we can finish 2.6 or give it more priority.
I have AppImage packages available for each project in case you want to test the scancode parts.
Columns already has all files included, so you don't need to get external data. it's easier to test with that one.
Since this is the main feature holding back the release, and it's been a few months and no major change happened in the 2.6 branch, I'm pushing again to see if we can finish 2.6 or give it more priority.
Agree, smaller bugs shouldn't be a reason to withhold a release, especially if there's anyway no work underway to fix them.
I think we have mostly converged on an API (correct me if I'm wrong), which is the most important part -- no backwards-incompatible changes after the release. Implementation can still be improved afterwards, and some bugs are likely only detected "out in the wild".
If we are not confident enough to stabilize the scancode API, it would also be possible to have a RC (release candidate), not sure if it's necessary though.
With #1235 finally merged, we're well under way to release SFML 2.6.
The more people we can get to test the latest version of the 2.6.x branch, the higher the confidence of a successful release. Get on testing then! 🙂
In the meantime, I'll close this issue.
SFML 2.6.0 has been released: https://github.com/SFML/SFML/releases/tag/2.6.0