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
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
- in the logs: the step footer will contain the latest version (and GitHub release page's link) along with the version you locked earlier
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.: firstname.lastname@example.org)
- for major version (e.g.: email@example.com or xcode-archive@1)
- for minor version (e.g.: firstname.lastname@example.org or email@example.com)
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.