search

openframeworks / openFrameworks

openFrameworks is a community-developed cross platform toolkit for creative coding in C++.
http://openframeworks.cc
Other
9.81k stars 2.55k forks source link

OF 0.12.1 Release Checklist #7588

Open dimitre opened 9 months ago

dimitre commented 9 months ago

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

iOS

macOS

msys2

vs

linux

emscripten

After Release

cjdg commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

on my list:

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

also revisit #7352

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

dimitre commented 9 months ago

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

dimitre commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

@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 commented 9 months ago

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

NickHardeman commented 8 months ago

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 commented 8 months ago

Maybe implement webMIDI for Emscripten? https://github.com/openframeworks/openFrameworks/pull/7259 Its already working, but I guess my implementation is not perfect ;)

dimitre commented 7 months ago

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

artificiel commented 7 months ago

if I may allow myself to refer to https://github.com/openframeworks/openFrameworks/discussions/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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

dimitre commented 5 months ago

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

ofTheo commented 5 months ago

🙂- 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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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: @.***>

danoli3 commented 5 months ago

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 commented 5 months ago

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: @.***>

dimitre commented 2 weeks ago

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

artificiel commented 2 weeks ago

in the top post list #6306 can be closed by pointing to https://github.com/openframeworks/ofSite/issues/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

dimitre commented 2 weeks ago

Great. I'll add some others I think are useful Idea: examples and tests can be formatted with clang format soon And just before release a pass over all core code.