I know the default/recommendation to use for Discourse versioning is tests-passed, but thus far our team has been specifying the Discourse version in the app.yml, eg version: 2.7.0.beta1. We do this because we want to be able to explicitly control which version exists on production.
However, we saw from this topic that there’s a bug that prevents us from doing this like we always have. This is an issue because of how we do autoscaling for our forum. For example, say that version 2.7.0.beta1 is currently on production. But then we get a surge of traffic on the forum, and we have to spin up another instance to scale for that. If we have tests-passed in the app.yml and there’s been another Discourse release since our last production update, it’s going to spin up a new instance (2.7.0.beta2) that conflicts with the existing one. So then we have two different versions out there, possibly with database changes and other compatibility issues, and it results in production not functioning correctly.
There’s also other reasons we may not want it to auto-update in such a manner, like plugin compatibility issues, and generally wanting to fully test things on staging before releasing to production.
As a note, we’ve been trying to get this solution to work so we can specify the Discourse version, but it’s currently failing with version 2.7.0.beta3. We get a bundler error similar to the one seen here, and I know that person’s solution was to go back to using tests-passed.
So my question is - how can we effectively control our Discourse versioning, given our autoscaling setup and general need to specify which Discourse version is deployed on production? I’d love to hear what others have done in this situation.