Open steve-bate opened 1 month ago
We need a thought-out approach for dealing with application versions, which we have sidestepped so far.
Node
implementations may only be able to be run with specific versions or version ranges of an application (that includes the case from #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.