SFML Roadmap

[eXpl0it3r]

I've just updated the first message.

[Thrasher]

I like this updated roadmap. We just merged yet another 2.6.1 fix so please keep using and testing 2.6.0 to find whatever remaining quirks there are so we can get them cleaned up.

When it comes to 3.0.0, I think the C++17-ification changes are almost done. Certainly there are no more big C++17 features to use. The remaining language usage upgrades are minor and/or can be done after 3.0.0 ships if need be.

As for API-breaking changes, those are harder to predict but I'd like to think most API changes are also done although some of the remaining API changes planned are pretty tough to write and test so don't expect them to get completed soon. My personal goal is to tentatively finish all these API breaks by the end of 2023 so we have time to let the API sit in a stable state while the final testing push occurs.

I expect we need on the order of >3 months of a stable API to be certain that what've written can withstand the test of time. I'm not sure where the other maintainers are at, but I'd like to ship 3.0.0 in the first few months of '24, hopefully soon enough to get it shipped into Ubuntu 24 LTS but that may be tough if we can't freeze the API by approximately November of this year.

[eXpl0it3r]

Having just tagged the first release candidate for SFML 3, it's time to take a closer look at the rough roadmap for SFML.

SFML 2.6.x

Since the 2.6.1 release November 2023, we've fixed a few more issues and plan to release 2.6.2 within the next few weeks.

Since SFML 2.6 is the final SFML 2 version, we will continue to merge critical fixes, as to support anyone not planning to update to SFML 3 anytime soon, but do keep in mind that the priority for it will be lower and fade over time.

SFML 3.0

SFML 3.0.0-rc.1 has been tagged, which in the grand scheme of things means, that we're mostly feature complete (the new dependency management is still awaiting testing).

We believe to have achieved the goals that we originally defined:

• Upgrading the SFML API for C++17
• Cleaning up redundant and deprecated code
• Adding features as we go along:
  • API breaking features only possible at a major version change
  • (low priority) Non-API breaking features

The plan moving forward is to do a lot of testing, hopefully with the help from all of you awesome people, to publish another release candidate within the next few weeks, and if all goes according to goes well, to release SFML 3.0.0 before the end of 2024. 🎉

Please report any issues, crashes, or general feedback, so we can make sure the SFML 3 release is as stable as possible.
Reach out: GitHub Issues / Discord / Forum / Twitter / Fediverse

SFML 3.1

Looking ahead, we have some pull requests open already that we put back into the "backlog", while focusing on getting SFML 3.0 finished up. We really hope to get those merged in SFML 3.1.
Additionally, we've made a few preparations in SFML 3.0, so we could add certain functionalities without breaking the API (e.g. the window state flag). Whether those will be added in 3.1 or later on, remains to be seen.

• Bevel Shape Outline
• Text alignment options
• To consider:
  • Opus with the new dependency setup
  • Window State & Styles
  • Monitor API (Solution Design)

SFML 3.2

One thing we really want to change, is to have shorter release cycles.
We'll have to see how this plays out, since it still heavily correlates with how much free-time each of us can invest.

Having said that, the plan is to not let the scope of SFML 3.1 balloon too much, as such here are already some ideas that might make more sense to do in SFML 3.2 instead.

• Complex Text Layouts with HarfBuzz
• QOI & QOA Image and Audio Format Support

SFML 4

In the very first maintainer meeting, we decided to not change the underlying rendering API dramatically foro SFML 3 and focus on getting C++17 support out of the door.
But we also recognize that SFML's legacy OpenGL usage is a top priority, as it's preventing the use of the graphics module in quite a few scenarios, as well as not being able to use of OpenGL ES 2.0 or supporting Emscripten.

As such, the primary focus for SFML 4 will be to update the underlying rendering API. Whether this will bring support for multiple rendering backends or help with batching support, remains to be seen.

It's also very likely, that we'll be updating the C++ standard to require C++20, which should allow us to use std::expected and (C++23 feature) do more internal clean ups.