Version will be required in type: what it means for your projects

Platform.sh makes configuring applications simple with a collection of YAML files in your project repository. Any project can specify the application’s language and the services it has access to using the type keys within .platform.app.yaml and services.yaml, respectively, as well as their versions.

Although the documentation recommends including a version in type, it hasn’t been required, so users could simply define a PHP application with type: php instead of the full type: php:7.3. Beginning 1 August 2019, Platform.sh will no longer support type without a version specification, and pushes that don’t include versions for each image will be rejected.

What’s changing?

Projects on Platform.sh will no longer be able to configure runtime and service containers without including a supported version in type as recommended in the applications and services documentation. When the change has rolled out to every region, projects that don’t specify a version will be refused when attempting to push that configuration to Platform.sh, returning an error.

When will the change take place?

Beginning 1 August 2019, the change will roll out until it’s been made across all regions.

Why the change?

Today, if projects don’t include a version for a container, a default version is added to the cluster in its place.

The main problem with this approach? Inconsistency. The default version can vary by project region for a variety of reasons, making the same project with the same code fundamentally different between regions.

To avoid surprise upgrades, we also don’t update the default version. The default versions are generally quite old and often a version of a service that's no longer supported by the vendor with security updates. So, using them in production isn't a best practice.

From the onset, our documentation has recommended including a version, in part because doing so makes your configuration clearer to everyone working on it. When a version is defined, you know exactly what's running in production, and it gives you a simple and intuitive place to test the application with new releases by simply editing that version on a new branch.

How will this change affect you?

If your projects already include versions for each of the services and languages your application uses, the change won’t affect you at all.

On the other hand, if any of your project configurations exclude a version (like this):

rediscache:
  type: redis

you’ll receive an error when pushing to Platform.sh.

services.redis.type: The version needs to be specified in type “redis”

In that case, you’ll need to update your services.yaml file to include a supported version listed in the documentation,

rediscache:
  type: redis:5.0

You can find a full list of supported versions for each service on their individual pages in the services documentation and for each language here:

• PHP supported versions
• Python supported versions
• Node.js supported versions
• Java supported versions
• Ruby supported versions
• Go supported versions

To ensure that there’s no disruption in service in relation to this change, the Platform.sh team has identified the projects that will be affected and will be sending an email to each user to instruct them about which projects require updates to their configurations.