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:

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.
The Mobile DevOps Newsletter

Explore more topics

App Development

Learn how to optimize your mobile app deployment processes for iOS, Android, Flutter, ReactNative, and more

Bitrise & Community

Check out the latest from Bitrise and the community. Learn about the upcoming mobile events, employee spotlights, women in tech, and more

Bitrise Insights

Cache | Caching

Mobile App Releases

Learn how to release faster, better apps on the App Store, Google Play Store, Huawei AppGallery, and other app stores

Mobile DevOps

Learn Mobile DevOps best practices such as DevOps for iOS, Android, and industry-specific DevOps tips for mobile engineers

Mobile Testing & Security

Learn how to optimize mobile testing and security — from automated security checks to robust mobile testing and more.

Product Updates

Check out the latest product updates from Bitrise — Build Insights updates, product news, and more.

The Mobile DevOps Newsletter

Join 1000s of your peers. Sign up to receive Mobile DevOps tips, news, and best practice guides once every two weeks.