I see a couple of possible options: 1) Implicitly test against a matrix of SM versions because we use the packages that are shipped with each supported OS in the CI matrix, e.g. CentOS8 -> SM60, Ubuntu 20.04 -> SM68, Debian 11 -> SM78 (that last one’s not in Jenkins CI yet I think). In this model we only add official support for new SM versions when they show up in a supported distro.
2) Reinvigorate the couchdb-pkg machinery we use to generate SM 1.8.5 packages to publish .debs for all supported SM versions, then add a new matrix build to verify support. I guess the key question is whether we expect users to continue to depend on distro packages for their actual production installation. If so, then I’m not sure a separate matrix offers a great return on investment. We could easily end up in a situation where CouchDB works with the SM package that we built for CI, but not the one the distro maintainers ended up publishing. That said, if someone wants to do the work, great! An option to trigger a manual integration run against a specific version of SM also seems like an OK compromise to me. Adam > On Nov 26, 2021, at 5:23 AM, Jan Lehnardt <j...@apache.org> wrote: > > Hey all, > > we recently received a nice contribution (SpiderMonkey 91 support) as a > community contribution: > > https://github.com/apache/couchdb/pull/3842/files > > It includes a GH workflow that includes building said SM version to prove > that it works, which is very nice. > > We currently don’t really test a matrix of SM versions, and we probably don’t > want to build sm from source on each CI run. > > My question to you is how you think we should handle this? > > Best > Jan > — > Professional Support for Apache CouchDB: > https://neighbourhood.ie/couchdb-support/ > > 24/7 Observation for your CouchDB Instances: > https://opservatory.app >
