chore: Use SpiderMonkey v128 as default version

[big-r81]

No description provided.

[nickva]

We'd have to make sure packaging works well with the change. Run a full ci build (git checkout to jenkins-* brach and then git commit --amend --no-edit && push).

I started one here: https://ci-couchdb.apache.org/job/jenkins-cm1/job/FullPlatformMatrix/job/jenkins-sm-128/1/pipeline-graph/

edit: looks good!

[big-r81]

Hey Nick,

I tried too, but I got an error for CentOS 8, because it's landed on the ARM64 worker and because it is using SM60, it failed. See https://ci-couchdb.apache.org/job/jenkins-cm1/job/FullPlatformMatrix/job/jenkins-sm-v128-default-version/1/pipeline-console/?selected-node=409

Another interesting case (but unrelated to the PR):
The same CI run is green, but one specific test fails: https://ci-couchdb.apache.org/job/jenkins-cm1/job/FullPlatformMatrix/job/jenkins-sm-v128-default-version/1/pipeline-console/

[nickva]

I tried too, but I got an error for CentOS 8, because it's landed on the ARM64 worker and because it is using SM60, it failed. See https://ci-couchdb.apache.org/job/jenkins-cm1/job/FullPlatformMatrix/job/jenkins-sm-v128-default-version/1/pipeline-console/?selected-node=409

Another interesting case (but unrelated to the PR): The same CI run is green, but one specific test fails: https://ci-couchdb.apache.org/job/jenkins-cm1/job/FullPlatformMatrix/job/jenkins-sm-v128-default-version/1/pipeline-console/

Hmm we may have to change the labeling scheme for how workers/hosts/guests find each other to run CI builds. Now we have a generic docker label because initially it meant they were all x86_64 basically, but we may have to find some other scheme: we may have to look the docker label but also at the os.arch (ex.aarch64) system property as well...

[big-r81]

Do we have an option for CentOS 8 to update SM to a version > 60?

[nickva]

Do we have an option for CentOS 8 to update SM to a version > 60?

Ideally we shouldn't have to. CentOS 8 should be shipping with its original SM major version and RH should be providing updates and security patches for if. If SM 60 comes from the EPEL repo then maybe there we can update it but if it's included in the base package set if we update it we'd be on the hook of maintaining our patches and security updates and such.