the concept of releases

[artificiel]

these days a certain amount of forum responses are "try the nightlies". in itself, that's a symptom of something, which is the emergent pattern of continuous development in git. it raises the question: what does a "release" mean for OF.

while tracking a "rolling release" might be fine for some (in essence, what the nightlies are doing), there is value in having easily-referable packaged binary releases, notably for support, and also teaching (same codebase for a given cohort).

but the moment of a release has more meaning that it’s “version number”. so saying “this was made with OF2021-3” is more meaningful than OF11.3.2.

also, it is a difficult project-management task to plan the effort required in a checklist of features "to be realized in a reasonable window of time", especially considering how energy flows in open source projects: it is not possible to count on deadlines or "crunches" to complete such a list.

i thus propose to drop the semantic versioning concept, and adopt a form of tag-release that makes it easier to produce fresh versions of OF. the rules to generate such a release could be a mixture of significance (a major rework or specific addition provokes it) and time (if no release has been done in 4 months, retroactively tag the most recent stable commit).

beyond removing the pressure to "execute a release”, it removes the looming spectre of the asymptotic OF 1.0… and, marketing-wise, more frequent releases will make it apparent that OF is "alive" (which, to me, has more impact than revamping the website).

[ofTheo]

Hi @artificiel thanks for this!

i thus propose to drop the semantic versioning concept, and adopt a form of tag-release that makes it easier to produce fresh versions of OF. the rules to generate such a release could be a mixture of significance (a major rework or specific addition provokes it) and time (if no release has been done in 4 months, retroactively tag the most recent stable commit).

beyond removing the pressure to "execute a release”, it removes the looming spectre of the asymptotic OF 1.0… and, marketing-wise, more frequent releases will make it apparent that OF is "alive" (which, to me, has more impact than revamping the website).

Personally I like this thinking - I feel like Releases have been a high pressure / high expectation thing which ends up delaying people getting meaningful improvements. There are also so many fiddly steps that are easy to mess up that it ends up being quite an involved process.

I like the idea of monthly picking the most stable commit and just making that OF-Stable or OF-Latest ( and maybe tagging with a date like you suggest ).

I'd be curious what others in @openframeworks/core @openframeworks/openframeworks-devs and the rest of the community think?

[dimitre]

I too think we should have a monthly release no matter what. maybe using tags, for me it is good to keep the previous number system but it is great to think of dates too.

I thought the issue with new releases was only the process of automating building libs for all platforms and packaging using github actions.

[ofTheo]

I thought the issue with new releases was only the process of automating building libs for all platforms and packaging using github actions.

That will make it a lot easier, but there is also parsing the GitHub commits for the Changelog and some other processes. Most which can be automated.

I also keep telling myself "don't let perfect get in the way of good enough" 🙂 and I think people will maybe appreciate more up to date releases at the cost of the changelog not being so pretty / nicely formatted etc.

[dimitre]

Yeah I like the way this project only have some items in the changelog then point to all the commits between one release and another to point the full changelog
https://github.com/chalet-org/chalet/releases/tag/v0.5.21

[ofTheo]

yeah - that's perfect actually! the data is already there in the compare :)

[Daandelange]

I'm using github-clones for latest features, experimenting, and trying branches, while I use stable release zip downloads mostly for testing before releasing ofxAddons and ofApps. Marking/tagging more frequently "stable" releases could certainly be useful in terms of feedback reactivity from the community, for feeling more confident when picking a master commit to work with for a while, and for giving more flexibility to deadline managing. I also agree that it will help reflect OF's "aliveness"/acitivity better and prevent the symptom.

Regarding the zip release download, we must also keep in mind disk space. I don't know about you, but I have 2 folders per major release with all projects within it : one GIT and one release. On each new release that I choose to work with, I start with fresh addons and duplicate my ofApps one by one as I need to upgrade them to that OF version. After a few OF release versions I end up archiving the older ones with all my projects in it, but I often need to check stuff back in there. Making more frequent releases will definitely not enhance this workflow, but as I don't use all released versions, it won't interfere much. To me, tagging (release) versions is useful in terms of flagging a major stable release to work with for a while. This is particularly useful when multiple people are collaborating on a same OF project. I don't use the nightlies, probably because it saves me some new version folders, and having OF as GIT repo allows to switch on demand.

Regarding the release notes, automatic generation is fine while it's a pleasure to read a clean changelog, it will however lighten the release workflow and it can also encourage writing better commit messages and grouping them, which is also useful on a more global scope.

About semantic versioning, it is useful to me for indicating breaking changes without reading changelogs. It's not that much work associating a version number to a year if you need to. Nothing prevents us from making more frequent releases with semantic versioning.

In short: I like the current versioning and release schemes, but they could be slightly adjusted in frequency. The nightlies could become more serious, or releases more automated and more frequent, which will help OF reflect its internal activity to the community.

[2bbb]

monthly (or interval close to) release is sounds good.

I don't know many about semantic versioning, but I guess major (oF uses minor as major-ish...?) version is helpful for understanding api changed.

Couldn't we use versioning like 0.12.2023-02?

[artificiel]

after reading the insightful comments above i realize my proposal lumps a few things: 1. semantic vs tag-date; 2 development dynamics; 3 usefulness of a "curated binary package"; and 4. frequency of such releases.

1. my take on tag vs semantic is mostly about pressure and overhead: adhering to a meaningful semantic scheme takes forward-looking planning and oversight. inversely a tagged-date release is more like the ascertainment of a chunk of "done" work: at a certain moment, existing contributions are folded into a release. i'm not against sequence numbering, but it does not mean much unless there is a master-plan, roadmap etc (and to be honest i'm not sure i've ever made use of a version to consider API breakage vs just trying it out). on the other hand rolling-release and/or tracking-git is more and more of a norm in many projects. having the year in the name of a binary package is a great way to provide a sense of out how far back it dates.

2. OF 0.12.0 Release Checklist #6692 might never be "done" — and of course this is not to be construed as criticism vs core/ofTheo (quite the contrary the effort is amazing) — but there is a natural limit to the self-organizing-management of large github-issues-managed projects, due to the fact that energies flow irregularly, and that authority and initiative have to be coordinated. and also unfortunate: work not on that list has been done in the past 2 years and is not reflected in a recent release (hence my initial remark vs forum solution which are "try the nightlies"). when a chunk of development in done, that work can trigger a release, and in it's wake pull a bunch of tweaks and fixes, regardless of a master semantic version logic (there are so many areas in OF that a given release might break something in some corner of the API (although the effort is never to do it and instead deprecate and use different names)). if nothing of significance happens for a while, a release can still be generated (it could be "just" a handful of bug fixes: no pressure on the "significance" of the release as it's a curated snapshot at a convenient moment in time).

3. to continue @Daandelange's self-description of usage: most of my work happens in my OF git fork; if i make something that must be delivered/supported i will base it on the latest binary release populated with current copies of required addons. my own code is not under apps/myapps but in it's own project repository (using PG or .qbs to map it to correct tree). when all is done i archive everything (thus, either the git or the release repository with the relevant addons plus my own repo) and store it somewhere for perennity (at that point i consider that it's my (or my curator's) problem). i will sometimes use nightlies to quickly install a version on a fresh machine. beyond my personal usage i see the value for a binary "official" release to simplify teaching (so i can instruct "install OF2023-02", and prepare my material against that) or when an older project breaks (having a user be able to say "it was made with OF2014-02 and works up to OF2022-01" helps to pinpoint the breaking change, without being git-fluent).

4. most people will start by downloading the most recent binary release, and as such, as long as it's been within a couple of months i think it passes as being "pretty fresh". to that effect as for the frequency, my proposal implies more of a semi-annual affair than a monthly affair... the idea is not to create another pressure point (!), but on the contrary to provide a kind of valve that can be purged now and then.