Api-request: function that returns Osara-version

[mespotine]

I would like to as for an API-function, that returns the version-number of the currently installed Osara-extension.

Something like:

string version, string pre_buildnumber = reaper.osara_GetInstalledVersion()

I would like to use more Osara-features in some of my future scripts that I want to share as well. But I need a way to check, whether somebody has the right version installed on their system. That way, I could warn, that my script might not work on their system due to an outdated version of Osara being installed.

Other extensions like SWS, JS-extensions, ReaPack, etc have this as well and it's extremly helpful for giving feedback to users if the wrong version is installed.

[ScottChesworth]

Hey @mespotine, good to see you showing up here! We've chatted a bit on the forum, I'm scottsdale over there. @jcsteh, I've labeled this P1 because other scripters have also requested it, I just forgot to open an issue earlier.

[mespotine]

Thanks :)

[jcsteh]

I'm really not a fan of version detection, especially for a project like OSARA where we don't have official versioned releases; users just use snapshots. That makes version numbers even more unreliable than they usually are. The only "reliable" part of OSARA version numbers is the commit hash and you can't really compare those. The build number is just an ever increasing number on AppVeyor, but that increases even for PR builds, etc.

A better way of doing this would be feature detection, but to do that, I'd need some idea of what kind of features you're trying to detect. If it's API functions, you can just test whether the function can be retrieved. But there aren't many API functions at this point, so I'm guessing it isn't that.

[mespotine]

Ok, I understand the problem with the build-hashes to be problematic. Would it be possible to return something else instead, like the date of when the build was created? Something like yyyymmdd would work real good for version-comparison.

In regards of checking for feature availability, this would not work, at least not fully. Checking for existence of features would be easy to do in most cases, however, checking for changes in already existing features would be extremly difficult or even impossible.

Let's take a theoretic example: Osara has the feature to report markers during playback. Now imagine, that the devs of Reaper add a new type of project markers, so that we have markers, regions and this new markertype. Somebody will probably ask you, to add these new markertypes also to be reported, so you'll probably add it.

Now imagine, I have an accessibility-script, that works with the new markertype and needs Osara to report the new markertype as well. How can I find out, if the "Report markers during playback" supports reporting this new markertype in the currently installed version? I can't. But, if I have some kind of version-number, I can compare the version-number. And if the version is lower than the one I need, I can at least warn, that reporting of the new markertypes are not supported in the currently installed version of Osara. And that a new version should be installed, instead.

The same thing goes for API-functions and actions. I can check, if they exist, but not, if a certain change or even a needed bugfix has been added yet. I can determine this only with a version-number. (With "Report markers during playback", I couldn't even find out that the feature already exists in the current version. Unless its extstate is stored yet which only happens after hitting ok in the preferences at least once.)

I had this problem a while ago with SWS as well. I could only find out, whether a feature existed, but not, if changes/bugfixes in API-functions or actions were already part of the currently installed version. So I requested a get-version-function which solved the problem completely.

With this, we can give users of scripts meaningful feedback so they know, what to do if stuff doesn't work, like "please update Osara to a version built after date yyyymmdd".

[jcsteh]

I think depending on functionality you can't directly control is fragile. OSARA might support reporting of a marker type, but you don't necessarily know what actions or other behaviour will trigger that reporting and that could change from version to version; it's entirely an implementation detail.

Nevertheless, I guess the full version number is the best we can do here. I think a date is even less reliable than our current version numbers, so I guess we'll just expose the full version number and let consumers handle it how they will.

[mespotine]

Thank you :)

One more question: I've seen, that Osara does a lot doing pre-releases, if I got it right. Is there occasionally a "final version"? Like at the end of the year, the 2022 version becomes the full one and the one for 2023 becomes a pre until the end of 2023? How do you currently handle this?

[ScottChesworth]

we've not had a milestone version yet. Talked about it a few times, but I'm always worried about it discouraging adoption.

[ptorpey]

Interesting you should say that. I’ve always been a bit reluctant to download the releases that look like “pre releases” on GitHub since one might not be sure if they are wrung out. On the other hand, I am not relying on the tools for a possibly time sensitive professional job and always like testing pre release or beta software since it provides an opportunity to give feedback before code is baked in. so I, personally, usually will download these incremental releases.

Actually, I often just hold off until I see a new function or fix implemented that I think I might make use of and download that version (usually keeping the old version just in case).

But I wonder if some other’s might just hold off waiting for an “official” release if they have different circumstances or requirements.

Don’t know. Just a thought.

--Pete

[jcsteh]

Ultimately, official releases only make sense if there's some quality bar that differentiates them from snapshots. Just choosing some point in time and saying "this is a release" is arbitrary and doesn't guarantee anything. For example, there might have to be a period of time where the release branch is frozen and accepts no new features so we can guarantee stability before we ship it as a release. It also requires that we have a set of users testing both branches.

Personally, I don't have the time to maintain something like this. I could maybe do yearly releases or something, but I think they'd be so far behind that most users wouldn't use them, especially given the pace of REAPER development.

[ptorpey]

I wonder if perhaps it might make sense to make it a new release when/if the keymap changes so that everyone is on the same page about hotkeys?

--Pete

[RDMurray]

It would be really nice if the version number was more human readable. How about date+git hash? I.E 2022-06-12.94f8ecef. I think it would make communicating about versions much easier.

[jcsteh]

The build number really does need to be included for differentiation between failed builds if nothing else. We could probably drop the 2022.1pre though. That's in there because it allows us to easily switch to version numbers in future (2022.1, 2022.2, etc.), but I guess if we're never going to do that, we can drop it.

Note that while it's possible to encode the current version number strategy into a binary version number (e.g. 2022.1.13594), it gets much harder if we move to a version based entirely on the date.

[jcsteh]

Our build version numbers changed recently to be like this: 2024.3.1.1313,64bffe69 That is: year.month.day.build,commit @mespotine, are you happy for this string to just be returned as is?

[mespotine]

That is fantastic and would do it. Thanks!  Am Mittwoch, 6. März 2024 um 13:15:53 MEZ hat James Teh @.***> Folgendes geschrieben:

Our build version numbers changed recently to be like this: 2024.3.1.1313,64bffe69 That is: year.month.day.build,commit @mespotine, are you happy for this string to just be returned as is?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>