Skip to content

OF 0.12.1 Release Checklist #7588

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
46 of 54 tasks
dimitre opened this issue Aug 7, 2023 · 108 comments
Open
46 of 54 tasks

OF 0.12.1 Release Checklist #7588

dimitre opened this issue Aug 7, 2023 · 108 comments
Milestone
0.12.1

Comments

@dimitre
Copy link
Member

dimitre commented Aug 7, 2023 •
edited by ofTheo
Loading

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

arm

android

  • get android working again
  • fix all examples (some deprecated code)

iOS

macOS

msys2

vs

linux

emscripten
@dimitre dimitre added this to the 0.12.1 milestone Aug 7, 2023
@ofTheo ofTheo pinned this issue Aug 29, 2023
@cjdg
Copy link

cjdg commented Aug 29, 2023

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

@ofTheo
Copy link
Member

ofTheo commented Aug 29, 2023

hmm that's strange @cjdg - I can see it here:
https://launchpad.net/ubuntu/lunar/+package/libopenal-dev

did you try:
sudo apt-get upgrade

to upgrade the packages on your system?

sometimes I find aptitude can handle these installs better.

sudo apt-get install aptitude
sudo aptitude install libopenal-dev

@artificiel
Copy link
Contributor

artificiel commented Aug 31, 2023 •
edited
Loading

on my list:

misc #7620 #7621 #6939 #7565 #7271 #7031 #7122
install from GitHub streamline #7606 + #7607 + #7609
deprecate cleanup #1550
default to release #1022

also revisit #7352

(also: can close #7016 #1748 #1966 #7414 #7517)

@dimitre
Copy link
Member Author

dimitre commented Aug 31, 2023

This one is a personal favorite to be discussed and maybe solved

@dimitre
Copy link
Member Author

dimitre commented Aug 31, 2023

One thing to plan for next release is if it will be compatible for c++14 or c++11 yet.
I think it is good ot make another release backwards compatible before start incorporating c++17 exclusive on the core.
This way we can get @danoli3 huge PR goodies in macOS 10.14 or earlier. what do you think ?

@ofTheo
Copy link
Member

ofTheo commented Aug 31, 2023 •
edited
Loading

I'm leaning towards c++17 only for the next release, with no boost.
Apothecary has sucked up so much time for me and for others - the smaller the dependency list the better.

For OF we have always tried to support the last three versions of macOS and so that would be macOS 13, 12, 11 now.
10.14 is really out of date at this point.

People can also use 0.12.0 if they need < c++17.
Are you still on 10.14 @dimitre ? 🙂

Edit: that said maybe next release is 0.13.0 and 0.12.1 is a patch-fix release only if needed.

@artificiel
Copy link
Contributor

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.

@ofTheo
Copy link
Member

ofTheo commented Sep 1, 2023

@artificiel that is correct but it does currently rollback to C++11 / 14 and uses boosts filesystem if C++17 filesystem is not available.

See: https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/utils/ofConstants.h#L487

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.

@danoli3
Copy link
Member

danoli3 commented Sep 1, 2023

Awesome yes yes! Okay deployment time, I'll summon the merge this week

@ofTheo ofTheo mentioned this issue Sep 2, 2023
Merged
@NickHardeman
Copy link
Contributor

This one is a personal favorite to be discussed and maybe solved

@dimitre Yes! I can add this to my list. :) Would love some more input on how ofSetColor(int c); should be handled.

@Jonathhhan
Copy link
Contributor

Maybe implement webMIDI for Emscripten?
#7259
Its already working, but I guess my implementation is not perfect ;)

@dimitre
Copy link
Member Author

dimitre commented Oct 6, 2023 •
edited
Loading

We can assign open issues from older milestones too, if they are pertinent to this release
https://github.com/openframeworks/openFrameworks/milestones

@artificiel
Copy link
Contributor

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.

@ofTheo
Copy link
Member

ofTheo commented Oct 7, 2023

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,

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.

@artificiel
Copy link
Contributor

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:

  1. probably a fair amount of regular yet non-developer users would get on such a git-latest if it's made simple and safe to do so, as it might be a bit of a pain to constantly re-download the whole nightlies as a package and fiddle with PG to refresh projects (or rename/replace directories, etc). in order to maintain a bit of coherence there (and also get all the tests passed "in private"), the PRs should be buffered in a form of "develop" branch (or perhaps "bleeding" as I recently noticed in apothecary). Then merged to main/stable/latest to produce the packages and clear the slab.

  2. there is still a need for "reference" (or perhaps kind of "LTS"?) releases, specifically for workshops/teaching context where it should be simple to base work on a specific version of OF. I guess that's what I'm thinking of in terms of "releases": a point in time that marks a fair amount of done work, that gets tagged and archived when the timing is right. 2-3 times a year would be plenty.

[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).]

@artificiel
Copy link
Contributor

artificiel commented Oct 9, 2023 •
edited
Loading

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")

  1. drop-replace their OF in-place (being careful with stuff in apps/myApps and addons... dangerous)

  2. Install newest-latest besides older-latest and move/copy over their work and addons (needs to be careful as to "which version" contains their up-to-date work... less dangerous but error-prone, and boring if done often)

  3. keep their projects out of OF and drop-replace OF in-place so PG is not required (a bit fragile, is not following the current "natural" ofApps default, and addons are still an issue) — this would be the behaviour with a platform-package-manager providing OF (homebrew, AUR, etc).

  4. keep their projects out of OF and keep different versions of OF (safe thing to do to easily rollback), copy addons around, and "re-associate" with PG.

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):

  • is ofApp/myApps still the correct approach? (it's the most dangerous aspect of overwriting -- if by defaults projects are out of OF, it simplifies the problem).

  • Is it possible to "upgrade" a binary release to track git? So once you got hold of a release, you "git pull" to track latest? (Something will also need to facilitate download_libs). Maybe an "update OF" button in the OF tab of PG so it can be done terminal-less?

  • Or maybe it's not git but a new script "update OF"?, that does something more intelligent with the latest package download (to not overwrite addons and apps/myApp)? Maybe CMake and the work done around it can help on that side?

  • Or maybe (for now) telling someone to "upgrade to the latest" is still a relatively exceptional troubleshooting event? which means the default install-upgrade workflow stays based on less frequent "LTS" releases (with the same upgrade problem, but not expected to be as often). and users-consumers wishing to be on latest need to learn to be git-based (like it's already possible, but with a clearer policy to track latest vs develop).

@artificiel artificiel mentioned this issue Nov 26, 2023
Merged
@dimitre
Copy link
Member Author

dimitre commented Dec 12, 2023

I would love an end of year version 0.12.1
The CFLAGS projectGenerator fix is enough for "unrecommend" 0.12.0

@ofTheo
Copy link
Member

ofTheo commented Dec 12, 2023 •
edited
Loading

🙂- yeah lots of stuff since 0.12.0
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. 💪

https://github.com/openframeworks/apothecary/releases/tag/bleeding

image

@artificiel
Copy link
Contributor

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 ofSite but: how do we get https://openframeworks.cc/documentation/ to be refreshed? the front page says it refers to 12.0 but most source is 5-7 years old and refers to 10.0 ex: https://github.com/openframeworks/ofSite/tree/master/documentation/utils

@artificiel
Copy link
Contributor

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.

@danomatika
Copy link
Contributor

danomatika commented Dec 13, 2023 via email

@danoli3
Copy link
Member

danoli3 commented Dec 14, 2023

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

@danomatika
Copy link
Contributor

danomatika commented Dec 14, 2023 via email

@ofTheo ofTheo mentioned this issue Dec 23, 2023
Closed
@dimitre
Copy link
Member Author

dimitre commented May 15, 2024

It would be great to have a 12.1 bugfix release anytime soon

@artificiel
Copy link
Contributor

artificiel commented May 16, 2024 •
edited
Loading

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
#7736 #7900 #7943 #7969

easy / nice to have:
#7925 #7755 #7740 #7685 #7607 #7606

let's discuss (merge or close):
#7696 #7922 #7683 #7680

@moebiussurfing
Copy link

moebiussurfing commented Apr 12, 2025 •
edited
Loading

Currently testing of_v20250412_vs_64_release
Project Generator do not allows drag a project folder well:
it do not loads the addons listed on addons.make
If I import the folder manually (using import button), it works fine.

@danomatika
Copy link
Contributor

Here is a bugfix relating to ofURLFileLoader POST requests: #8428. I think it's a simple fix.

@dimitre
Copy link
Member Author

dimitre commented Apr 17, 2025

My suggestion for the final checklist for release:

  • move aside of script until after the release
  • change "rc1" string in ofConstants.h

@ofTheo
Copy link
Member

ofTheo commented Apr 17, 2025

@dimitre - sounds good!
I can do the of script via create_package so it doesn't need to get removed from the repo.

@ofTheo
Copy link
Member

ofTheo commented Apr 17, 2025

Also - reminder for people on this thread RC1 candidate is out here:
https://github.com/openframeworks/openFrameworks/releases/tag/0.12.1-RC1

@moebiussurfing
Copy link

I am having errors with Kinect One camera using many new nigthly releases including RC1.
"of_v0.12.1-RC1_vs_64_release\examples\video\videoGrabberExample"

[notice ] 1: Kinect V2 Video Sensor
[ error ] ofDirectShowGrabber: initGrabber(): error allocating a video device
[ error ] ofDirectShowGrabber: initGrabber(): please check your camera with AMCAP or other software

@ofTheo
Copy link
Member

ofTheo commented Apr 18, 2025

@moebiussurfing did the Kinect V2 ever work with the regular ofVideoGrabber / ofDirectShowGrabber?
ie: does it work with 0.12.0?

I have only used it with ofxKinectV2 addon for grabbing the color stream.

Thanks!!
Theo

@moebiussurfing
Copy link

moebiussurfing commented Apr 18, 2025 •
edited
Loading

@moebiussurfing did the Kinect V2 ever work with the regular ofVideoGrabber / ofDirectShowGrabber?
ie: does it work with 0.12.0?

Yes, it was working perfect in 0.12.0. Also still working as system webcam too in Windows 11.

@ofTheo
Copy link
Member

ofTheo commented Apr 18, 2025

Wow - super weird.
Will check if anything has changed in ofDirectShowGrabber or VideoInput - thanks!!

@ofTheo
Copy link
Member

ofTheo commented Apr 18, 2025

@moebiussurfing Huh - there's been no changes to ofDirectShowGrabber that would make a difference since 0.12.0
and one small change in videoInput relating to device names.

Can you do this in ofApp setup before the camera is opened and paste the output?:

videoInput::setVerbose(false); 
int numDevices = videoInput::listDevices();

you might need:
#include "videoInput.h"

One other thing to try, is running your compiled exe as administrator.

@danomatika
Copy link
Contributor

danomatika commented Apr 18, 2025 •
edited
Loading

FWIW one of my Kinect V1 XBOX 360s is working ok with the kinectExample and RC1 on macOS 15.3.

@moebiussurfing
Copy link

moebiussurfing commented Apr 18, 2025 •
edited
Loading

Can you do this in ofApp setup before the camera is opened and paste the output?:

videoInput::setVerbose(false); 
int numDevices = videoInput::listDevices();

Getting same error.

[ error ] ofDirectShowGrabber: initGrabber(): error allocating a video device
[ error ] ofDirectShowGrabber: initGrabber(): please check your camera with AMCAP or other software

Image

One other thing to try, is running your compiled exe as administrator.

Nothing changed running as administrator neither on debug/release:

Image

@ofTheo ofTheo mentioned this issue Apr 18, 2025
Closed
@ofTheo
Copy link
Member

ofTheo commented Apr 18, 2025

oops so sorry - meant
videoInput::setVerbose(true);

Let's continue the discussion here:
#8431

@ofTheo
Copy link
Member

ofTheo commented Apr 19, 2025 •
edited
Loading

0.12.1 RC1 is currently failing on Visual Studio ( 2022 ) / Windows 11 .
Issue with linker error due to FreeImage missing symbols ( could be /MD related ).

Copying in 0.12.0 Freeimage lib and dll fixes it.
Needs to be fixed in apothecary - will open issue there.

cc @danoli3

Image

@moebiussurfing
Copy link

this example (videoGrabberExample) was working fine here also with Windows 11 / VS 2022...

@dimitre
Copy link
Member Author

dimitre commented Apr 19, 2025

@ofTheo can you test with this FreeImage for vs ? https://github.com/dimitre/ofLibs/releases/tag/v0.12.1

@ofTheo
Copy link
Member

ofTheo commented Apr 20, 2025

Will do @dimitre!
And good to know @moebiussurfing - I'll dig into it more, but wanted to mention it.

@danoli3
Copy link
Member

danoli3 commented Apr 23, 2025

@ofTheo just update your VS2022, seems like you have an old std_search installed. Microsoft changed some things and the GitHub runners use latest version

@danoli3
Copy link
Member

danoli3 commented Apr 23, 2025

Yeah just tested x64 / Debug / Release
arm64 / Debug / Release
All working

@danoli3
Copy link
Member

danoli3 commented Apr 23, 2025

The RC1 Windows Project Generator does not work (the packaged one though).
Downloading it manually does work though

@danoli3
Copy link
Member

danoli3 commented Apr 23, 2025

VS Release for ARM64 / x64 and ARM64EC does not include other libraries other than x64

@moebiussurfing
Copy link

moebiussurfing commented Apr 23, 2025 •
edited
Loading

The RC1 Windows Project Generator does not work (the packaged one though).
Downloading it manually does work though

Here it works fine (via import button), but you can't drag a project folder from file explorer. (I mean RC1 bundled PG)

@ofTheo
Copy link
Member

ofTheo commented Apr 23, 2025

@danoli3 - I just tried the RC1 release on Windows and the included projectGenerator.exe worked fine for me.
What was the issue you had?

@ofTheo just update your VS2022, seems like you have an old std_search installed. Microsoft changed some things and the GitHub runners use latest version

Thanks!
I did update and 0.12.1 RC1 works fine out of the box.

@alptugan
Copy link

Hardware:
Macbook Pro M2 Pro

OS:
15.4.1

Release:
of_v0.12.1-RC1_osx_release.tar.gz

Issue:
Project Generator; Drag & Drop action cannot locate project path, addons, and any other relevant data.
When I use the import button, it works as expected without issue. I can compile 3d examples without any issue.

Thanks!

@moebiussurfing
Copy link

moebiussurfing commented Apr 25, 2025 •
edited
Loading

Issue: Project Generator; Drag & Drop action cannot locate project path, addons, and any other relevant data. When I use the import button, it works as expected without issue. I can compile 3d examples without any issue.

Same problem here.
M1. macOS Sequoia 15.4.1. Xcode 16.2.
(In Windows too)

@ofTheo
Copy link
Member

ofTheo commented Apr 25, 2025

@alptugan @moebiussurfing - thanks for reporting I'll add to the PG repo.
Not sure if we'll get this addressed for 0.12.1 - I actually didn't know we had drag / drop support until you brought it up.

@danomatika
Copy link
Contributor

I also never knew drag and drop was supported by the PG. I always used the path picker via Import.

@artificiel
Copy link
Contributor

i knew; i knew!

but only the lower part.

@moebiussurfing
Copy link

moebiussurfing commented Apr 26, 2025 •
edited
Loading

Anybody tested of_v0.12.1-RC1_ios_release.tar.gz?

Here in macOS M1 Silicon / Sequoia 15.4.1 and Xcode 16.3 seems that not working.
Is not listing iOS devices or simulator, only My Mac (and do not works neither...)

Image

BTW
of_v0.12.0_ios_release.zip worked fine, except the iOS iPhone/iPad simulators:

Image

Compiling in my iPad device and selecting My Mac (Designed for iPad) worked too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.12.1
Development

No branches or pull requests