New options for locking step versions

We are introducing a new version management process for our steps from Week 9, 2020: you'll be able to lock for major and minor versions instead of the old always latest and specific versions.

UPDATE: This is now live. 🚀

We are introducing a new version management process for our steps from Week 9, 2020: you'll be able to lock for major and minor versions instead of the old always latest and specific versions.

TL;DR: Version-handling for steps changes from Week 9, 2020, but only for steps created after the release date. You can change "old" steps manually and we encourage you to do so gradually.

So far, you could choose from two options regarding the step versions you want to use:

  • Always latest
  • A locked version
undefined

From Week 9, 2020 and on, there's going to be a change in the options on the GUI (in the Workflow editor). You will be able to lock a step

  • for major versions: 1.x.x - so you'll get every update for that major version, nothing which might break your build
  • for minor versions: 1.5.x - so you'll only get the bugfixes but not the feature updates.
Note: We're using Semantic Versoning. Major versions might make the step break, minor versions are backward compatible feature updates, and patches are bug fixes.

This happens because locking to a specific old version of a step caused builds to fail unexpectedly sooner or later. Or when the step was locked on "always latest", then the new step updates with major version changes probably broke the build.

How will this new set of options solve this? We'll encourage our users to make the updates by notifying them

  • on the UI: you'll see that a step can be updated in the main panel of the step and the latest version you can update to
undefined
  • in the logs: the step footer will contain the latest version (and GitHub release page's link) along with the version you locked earlier
undefined

We're not changing anything that is already set. By default, if you add a new step, it'll be locked to the major version.

There is now a difference between the UI and CLI.  If you are an advanced Bitrise user editing the bitrise.yml directly, you can use all 4 versions of the step version settings:

  • always latest (stepID, e.g.: xcode-archive)
  • fix version (e.g.: xcode-archive@1.5.6)
  • for major version (e.g.: xcode-archive@1.x.x or xcode-archive@1)
  • for minor version (e.g.: xcode-archive@1.5.x or xcode-archive@1.5)

But if you set something in the YML and change it in the UI, you won't be able to change it back there. Sub-ideal? Maybe, but this will save a ton of trouble for the less experienced Bitrise users.

No items found.

Explore more topics

App development

Best practices from engineers on how to use Bitrise to build better apps, faster.

Community

Meet other Bitrise engineers, technology experts, power users, partners and join our BUGs.

Company

All the updates about Bitrise events, sponsorships, employees, and more.

Insights

Mobile development, latest tech, industry insights, and interviews with experts.

Mobile DevOps

Learn why mobile development is unique and requires a set of unique practices.

Releases

Stay tuned for the last updates, new features, and product improvements.

Get the latest from Bitrise

Join other Mobile DevOps engineers who receive regular emails from Bitrise, filled with tips, news, and best practices.