You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At a minimum, we'll want to document which Mastodon-like instance version is being tested and it would be easier (and less error prone) to ask the instance for that information.
It's not clear to me what versions the pseudo-Mastodon APIs report. I know some client apps require specific versions of Mastodon, so using an arbitrary version number could cause problems in those cases.
Also, by my counts, there are > 300 different Mastodon versions (not including Mastodon-compatible apps) deployed in the Fediverse. It could be interesting to test some of the older versions at some point.
The text was updated successfully, but these errors were encountered:
steve-bate
changed the title
Mastodon node: consider adding back server_version.
Mastodon Node: consider adding back server_version.
Jul 31, 2024
We need a thought-out approach for dealing with application versions, which we have sidestepped so far.
Reports should show the version of the application in it that was tested
Some Node implementations may only be able to be run with specific versions or version ranges of an application (that includes the case from WordPress Node: version problems #284)
Are there are other needs for the version?
We have Node.app_version() defined already, but only the sandbox and Imp nodes return something, But then, a NodeDriver should probably refuse to instantiate a Node if the Node implementation cannot handle the particular app version. So perhaps Node.app_version() should return something like self._parameters('app-version') that is being set by the NodeDriver based on whatever information it can get, rather than the Node itself.
So perhaps Node.app_version() should return something like self._parameters('app-version') that is being set by the NodeDriver based on whatever information it can get, rather than the Node itself.
For the Mastodon-compatible nodes, we don't need to put version in the parameters since we can get it via the API. Many other servers provide version information using an embedded nodeinfo endpoint. Non-Mastodon nodes could attempt a nodeinfo query to automatically get the version and then fallback to manually-configured parameters as a last resort if that fails.
At a minimum, we'll want to document which Mastodon-like instance version is being tested and it would be easier (and less error prone) to ask the instance for that information.
It's not clear to me what versions the pseudo-Mastodon APIs report. I know some client apps require specific versions of Mastodon, so using an arbitrary version number could cause problems in those cases.
Also, by my counts, there are > 300 different Mastodon versions (not including Mastodon-compatible apps) deployed in the Fediverse. It could be interesting to test some of the older versions at some point.
The text was updated successfully, but these errors were encountered: