Roadmap Sketch

[dimitre]

Just some ideas here. feel free to edit, comment, suggest.

0.11.3

API compatible with 0.11.2

0.12.0 - See Checklist here

• remove ofBox, ofLine, old deprecated functions ( Theo: But with #define to enable them if needed )
• change path functions to return fs::path instead of string. ( Theo: curious about other's thought on this - maybe 0.13? )
• remove math constants ( Theo: warning but available - allowing users to undefine them and remove warning )
• deprecate some path functions (addtrailingslash, removetrailingslash, etc)
• remove ofxPoco from core, move to a separate repo in openFrameworks (remove from apothecary?) 👍
• remove boost from core, maybe move to ofxBoost (remove from apothecary?) 👍
• maybe update minimum c++ to 14,
• Try to fix paths using space in windows / linux
• Try to fix paths using non latin languages in all systems

0.13.0

• remove deprecated functions in 0.12.0
• minimum c++ to 17
• move FMOD from core to ofxFMOD, so it is optional. ( Theo: suggest move to 0.13.0 - need a full release of deprecation )

[2bbb]

std filesystem is added from C++17.
at 0.12.0, if minimum C++ version is changed to 14 (not 17) then, can we remove boost actually?

[dimitre]

Yes, ofConstants.h is checking for two different experimental filesystem paths inside std, other than boost.
even using experimental filesystem from cxx11.
I think we even can remove boost now without breaking much backward compatibility

in order:

std::filesystem::path;
std::experimental::filesystem::v1::path;
std::experimental::filesystem::v1::__cxx11::path;
boost::filesystem::path;

[2bbb]

@dimitre

okay!
I didn't check coverage of experimental.
if experimental filesystem cover all of C++14 envs, then it is good to remove boost from core oF.

[ofTheo]

Thanks! @dimitre. Added some notes above. Agree on most, just maybe being slightly more conservative.
pinging @ofZach on this too

[chilina]

How about dropping armv6/armv7 support in favor of arm64? Maybe in 0.13.0 if it's not already in 0.12.0. Theo conducted a poll and got some comments on this a while back #7138.

[artificiel]

as a comment to the list above, propagating filesystem::path will reveal where assumptions are being made, and fixing these will probably fix most path problems in OF.

if I may add:

• evolve ofToDataPath et al. into a multi-directory strategy. this is triggered by the macOS bundle problem, but has additional uses. I have a backwards-compatible WIP for something that reflects what I wrote in ofToDataPath simplification #7368 but I have to make a better example before sharing;

• make sure sensible constructors are in as many places as possible to support a more declarative style Constructors in openFrameworks #1562;

• revisit the style, confirm if uncrustify is still the way to go, make an up-to-date style script, and reformat the code so it actually matches (right now the script styleWholeOF.sh mostly re-arranges the whole thing... which seems to indicate it does not reflect the current style as committed) Style changes - tabulated function names #7352;

and I will also stir the coals on #7320 as I'm still dubitative about the semantic version thing considering the development dynamics of OF. I will reiterate the crux of my argument: the pressure of "correctly" executing semantic versioning is a hindrance with little value (I'm not convinced about the "breaking API" thing in real-world use), and the friction it creates turns the nightlies into a de facto rolling-release. date-tagging "after the fact" from a develop into a main branch enables a much more fluid cycle.

[chilina]

I looked at #7320 just now. I like the idea of some kind of rolling release or a concept of mini-releases to capture important changes within some flexible interval.

A rolling- or mini-release might coincide with a reason why someone might choose the nightly over the current release, regardless of timing or frequency. Recent examples could include: c++17 support; gStreamer and video player and ubuntu 22.04 fixes; eliminating the prolific compiler warnings on macOS; fabulous new example projects from Nick Harman and Dan Buzzo; new classes in the core like ofShadow and ofCubeMap.

Each mini-release could be an opportunity to spotlight what's new or fixed or changed in a concise way. The blog might be a fantastic way to communicate and archive these changes.

However it works, I feel strongly that OF should (continue to) be super easy for beginners to download and get running in an IDE.

[dimitre]

speaking about libs removal (boost and poco) I think fmt would be a great addition to OF core.
https://fmt.dev/latest/index.html
https://github.com/fmtlib/fmt
what do you think?

[Jonathhhan]

The current ofxLua https://github.com/danomatika/ofxLua depends on boost, if I remember correctly (but thats the only case I know and maybe it can be updated eventually).

[dimitre]

Thanks for bringing this. I've opened an issue there

[artificiel]

Definitely, I’ve been using it for a while and it is the direct precursor to std::format which is already stable in c++20. So any work to adapt the various internal string things will be forward-compatible. (Probably the ofToString stuff should be deprecated in favor of fmt examples) Perhaps an of::format strategy would make sense here? Start with fmt::lib and move to std::format “for free” when OF goes c++20. [edit to remove stuff quoted via email]