OF 0.12.1 Release Checklist #7588
Comments
|
On Ubuntu 23.04, cannot install libopenal-dev, libopenal1 (= 1:1.19.1-2build3) pero 1:1.22.2-0ubuntu1~22.04.sav0 cannot be installed |
|
hmm that's strange @cjdg - I can see it here: did you try: to upgrade the packages on your system? sometimes I find aptitude can handle these installs better. |
|
This one is a personal favorite to be discussed and maybe solved |
|
One thing to plan for next release is if it will be compatible for c++14 or c++11 yet. |
|
I'm leaning towards c++17 only for the next release, with no boost. For OF we have always tried to support the last three versions of macOS and so that would be macOS 13, 12, 11 now. People can also use 0.12.0 if they need < c++17. Edit: that said maybe next release is 0.13.0 and 0.12.1 is a patch-fix release only if needed. |
|
I'm a bit confused I was under the impression that 0.12 was C++17 (namely std::filesystem, and also some constructs). In any case i agree that moving forward is the correct course of action, but it would be preemptive vs "long term support" good to document an upfront compatibility list, matching OF "epochs" to OS versions. I don't know about other platforms -- no windows, and on the linux side I'm with arch which is rolling and does not have a concept of version. |
|
@artificiel that is correct but it does currently rollback to C++11 / 14 and uses boosts filesystem if C++17 filesystem is not available. If we dropped boost from apothecary / OF then we would be saying you have to have full C++17 in your compiler to build going forward. |
|
Awesome yes yes! Okay deployment time, I'll summon the merge this week |
@dimitre Yes! I can add this to my list. :) Would love some more input on how ofSetColor(int c); should be handled. |
|
Maybe implement webMIDI for Emscripten? |
|
We can assign open issues from older milestones too, if they are pertinent to this release |
|
if I may allow myself to refer to #7320 TLDR my take is that releases should be as small and frequent as possible while being meaningful in one way (i.e. a certain central feature is structuring the release, and along with it comes a bunch of fixes, tweaks, etc.). so I would turn your question around and instead of thinking of more stuff, I would look at what's the major thing in "12.1" and draw a line around that. it is a break from semver, but as stated in the discussion above, proper semver creates overhead and pressure which does not really make sense for a toolkit as OF which will be forever in develop (reacting to the evolution of the platforms, IDEs, C++, concepts, etc). 1.0 is a wet dream with little purpose. instead of building an arbitrary, hard-to-estimate and impossible-to-manage "todo list" that defines a future release, work can be published as it accumulates. (it is not really "original" in thinking as such; the strict semver requirements of course have their use, but it applies better to dependencies (where you blindly include/upgrade a library) and takes for granted that you have the ressources to administer the process). it is simpler to consider the branch and determine "that's an interesting lump" and produce 2023.10. keeping things fresh and up to date across a bunch of platforms has inherent value, at least as much as maintaining backward-compat (specifically if the idea is to embark fresh users, and not just cater to old-timers getting their 007 projects out of their EZ135 backups). OF should not burden itself with administration. we see in the issues a lot of goodwill with tagging categories etc, as well as attempts to "organize" things, but entropy wins against such efforts because deep down the users-developers that want to contribute to OF-core must at some point make the active decision to allocate a part of their budget of brain-calories, and that comes out of one's other ongoing projects. it is one thing to "synergize" development momentum; it is another to end up with a task list that keeps growing. |
Ha - so true! :) Yeah, I think at the very least we should aim for nightly being considered the best one to use and normalize people working with nightly / latest. |
a rolling-release approach is certainly a possibility! I see 2 things to consider if that's going to happen:
[also, when I criticize semver it's not about number-dot-number scheme itself, but the focus about API breakage and dispatching changes/fixes/etc in major/minor/patches. In a continuous (and ostensibly chaotic) development process with so many loosely-coupled components as OF, the X.Y numbers mostly mean "a bigger chunk of changes" vs "a smaller chunk of changes" which requires an active "decision" to quantify... that's where i personally see a gain in simplicity with year-as-base-id — OF2023.2 is just "that year's second release" (and incidentally it instantly conveys more information about the context (contemporary OS/etc) than a numbered release).] |
|
Some considerations on a rolling release workflow — @ofTheo says "get people to nightly/latest". To that effect, the name "latest" seems the friendliest. To summarize: CI nightlies pop out of the develop/bleeding branch (where the action is the equivalent of the actual master/nightly one). The main (default) git branch becomes "latest", which is merged regularly from develop/bleeding, and produces curated "latest" packages as needed (probably not everyday). (*note that maybe also a better use of feature branches should be considered, but it's a diagonal discussion and non-blocking as long as there is a "buffer" branch before the end consumer). Users wishing to track with git will get updated to latest as they pull (and not get totally bleeding stuff or caught in a string of interdependent PRs), and users looking for a binary release will be oriented to get OF-latest. Users-developers can track develop if they wish. Super! The drawback to that workflow is for users getting OF through a packaged download: they will get "latest", which is fine initially. But then, what is the process for a user who got of-latest-20231012 and want to update to latest-latest 20 days later? (note: this is not different from upgrading the current packaged releases, only there is a difference between "an occasional upgrade event" and "a constant process")
None of the above are particularly smooth... Some thoughts (to reiterate: I am thinking here of the "official documented workflow", with in mind a fresh, non-terminal-savvy user that has not necessarily yet committed to dive deep at-all-costs into OF):
|
|
I would love an end of year version 0.12.1 |
|
🙂- yeah lots of stuff since 0.12.0 https://github.com/openframeworks/apothecary/releases/tag/bleeding 
|
|
if we are closing in I would like to petition for #7736 (critical, as we want the random distributions interface to be as close to "done" as possible (I've been using it regularity so I know it works but I'm still expecting to have to be reactive as people throw random things in the templated interface...)). also minor, but tighten things: #7755 and #7740 and tangential and probably belongs in |
|
also, I know there are efforts floating around and I don't know what actual "work" it means to wrap things but getting proper/explicit simulator support back for iOS would be an interesting 12.1 target. |
|
It probably involves changing the precompiled library format. From what I remember, the loader can't differnetiate between arm64 for mac and arm64 for iOS. The newer format is more like a bundle.I tried this for a native Obj-C app I have which used liblo built via makefile but I wasn't able to get either the new format to work or trying different ways of building a fat lib via ar etc. In the end, I made a static lib project and just build the C sources manually. A bit disappointing.Maybe the situation has improved since a year or two ago.enohp ym morf tnes-----------Dan Wilcoxdanomatika.comrobotcowboy.comOn Dec 13, 2023, at 12:34 AM, alexandre burton ***@***.***> wrote:
also, I know there are efforts floating around and I don't know what actual "work" it means to wrap things but getting proper/explicit simulator support back for iOS would be an interesting 12.1 target.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This can be solved quite easily with a script packaged with binary distributions of openFrameworks to convert the location to a git checkout targeting master. I tested this recently with great success. User can then decide what to do if fetching and discarding local changes and or pulling to latest via their normal git process.
Currently diving into validating VS libraries / linking due to the complexities of Windows CRT / Static / Dynamic etc - all has to be in sync and Debug/Release variants where using. Almost there now. Just addons the current battle
Yes all macOS, iOS, tvOS linking errors are to be completely obliterated shortly. The use of a new xcframework system (not in the latest binary tests on bleeding, as verifying linking / runtime verification, and this change will need some PG changes and xconfig adjustments accordingly ). The xcframework system lecture here: https://developer.apple.com/documentation/xcode/creating-a-multi-platform-binary-framework-bundle Code for this can be found here: https://github.com/openframeworks/apothecary/blob/3ddd0a76e13a97b7f4edccd1d1d59a125cbdd7bf/apothecary/apothecary#L1248 Basically once we get stability confirmed for new libraries, as many devs and projects we can throw at them to see what breaks the better |
|
Right, XCFramework is the new bundle name. Thanks for handling this. I didn't have luck the last time I tried.enohp ym morf tnes-----------Dan Wilcoxdanomatika.comrobotcowboy.comOn Dec 14, 2023, at 12:27 PM, Dan Rosser ***@***.***> wrote:
Users wishing to track with git will get updated to latest as they pull (and not get totally bleeding stuff or caught in a string of interdependent PRs), and users looking for a binary release will be oriented to get OF-latest. Users-developers can track develop if they wish.
This can be solved quite easily with a script packaged with binary distributions of openFrameworks to convert the location to a git checkout targeting master. I tested this recently with great success. User can then decide what to do if fetching and discarding local changes and or pulling to latest via their normal git process.
Would love to to get a 0.12.1 out. @danoli3 is there anything with apothecary bleeding you could use a hand on? its looking really close. 💪
Currently diving into validating VS libraries / linking due to the complexities of Windows CRT / Static / Dynamic etc - all has to be in sync and Debug/Release variants where using. Almost there now. Just addons the current battle
It probably involves changing the precompiled library format. From what I remember, the loader can't differnetiate between arm64 for mac and arm64 for iOS. The newer format is more like a bundle.I tried this for a native Obj-C app I have which used liblo built via makefile but I wasn't able to get either the new format to work or trying different ways of building a fat lib via ar etc. In the end, I made a static lib project and just build the C sources manually>
Yes all macOS, iOS, tvOS linking errors are to be completely obliterated shortly. The use of a new xcframework system (not in the latest binary tests on bleeding, as verifying linking / runtime verification, and this change will need some PG changes and xconfig adjustments accordingly ).
The xcframework system lecture here: https://developer.apple.com/documentation/xcode/creating-a-multi-platform-binary-framework-bundle
Code for this can be found here: https://github.com/openframeworks/apothecary/blob/3ddd0a76e13a97b7f4edccd1d1d59a125cbdd7bf/apothecary/apothecary#L1248
function frameworkFormula() {
LIBS_DIR_REAL=$(realpath $LIBS_DIR)
if [ ! -e "$LIBS_DIR/$1" ] ; then
echoVerbose " Nothing to create framework from to merge in lib dest dir: \"$1\""
else
rm -rf $LIBS_DIR_REAL/$1/lib/*.xcframework
echoSuccess " Framework lib dest dir: \"$1\" \"$LIBS_DIR_REAL/$1/lib/$TYPE/\" "
xcframework_flags=""
# Loop through each .a file built and make framework
for file in $(find "$LIBS_DIR_REAL/$1/lib/$TYPE/" -name "*.a"); do
echo "file $file"
xcframework_flags+=" -library $file -headers $LIBS_DIR_REAL/$1/include"
done
#echoSuccess " flags: \"$1\" \"$xcframework_flags\" "
xcodebuild -create-xcframework $xcframework_flags -output $LIBS_DIR_REAL/$1/lib/$1.xcframework
fi
}
Basically once we get stability confirmed for new libraries, as many devs and projects we can throw at them to see what breaks the better
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
It would be great to have a 12.1 bugfix release anytime soon |
|
in the top post list #6306 can be closed by pointing to openframeworks/ofSite#820 some old standing by: #7271 and if I may point to some of my own surplus to the backlog of pull requests (all mergeable): bugfixes / critical |
|
Great. I'll add some others I think are useful |
|
I would love a new release but we today have regression in libs in all platforms. |
|
Thanks @dimitre - yeah I wonder if we need a couple of lists.
|
|
@ofTheo not to hijack the thread but maybe combine this decision process with clarifying the status of git/nightlies which was evoked to become the de facto "go-to" version in a rolling release philosophy (with numbered releases as referable "milestones"), but clearly as of now it's been discussed in disparate issues regarding different contexts in relation to various problems and it's difficult to distill limpid points of views; unsure if the "comment thread" is the proper channel for such discussions. if this idea is to be seriously considered, a (FWIW I still subscribe to the view I presented in #7320 where I argue "semver" is not helpful for OF's development process). |
As I recall, the specific |
|
i can see the potential ambiguities (especially vs habits) with targeting the correct branch, but with current github web interface it's explicit to pull request into a specific branch and "visually confirm" the result is the one you expect before submitting. GUI git clients are getting pretty good too. it would be somewhat "involved" for an end-user to inadvertently pull for a first step, simply moving the dynamics of the current this to piggy-back on @roymacdonald's comment about "creating feature branches" -- now, everybody is always creating feature branches in their forks, but the only real manner of getting attention is to PR in having to bring this back to @ofTheo's last question, if moving to a
which seems to be mostly apothecary/libs/PG related. then once that's achieved, clone the branch to /develop and PRs are directed to that from now on. and if we're playing with names, |
Complete List - https://github.com/openframeworks/openFrameworks/milestone/27
Just starting a sketch of things that would be nice to work after 0.12 release, feel free to edit / suggest items
general / all
using namespace std;as the default fixing conflicting byte definitions #7628arm
android
iOS
macOS
msys2
vs
linux
emscripten
After Release
The text was updated successfully, but these errors were encountered: