Hello Habicats,
As part of the efforts to improve our release process, you’ll be seeing a change in how unreleased artifacts are versioned in Builder. The -dev suffix will no longer be used and instead the patch version will be incremented with every build. The packages whose versioning is affected in this way are as follows:
* core/hab
* core/hab-backline
* core/hab-pkg-aci
* core/hab-pkg-cfize
* core/hab-pkg-export-docker
* core/hab-pkg-export-helm
* core/hab-pkg-export-kubernetes
* core/hab-pkg-export-tar
* core/hab-pkg-mesosize
* core/hab-plan-build
* core/hab-plan-build-ps1
* core/hab-studio
* core/hab-sup
What does this mean for me?
For the majority of our users, this won’t change your daily usage of Habitat. What you can expect to see is instead of our releases (almost) always being a .0 release, the patch version will now represent the number of builds performed for a given minor release. For example, the upcoming release will be 0.90.6.
Who is affected?
If you have any environments that install from the unstable channel, or if you have a dependency on one of the Habitat components with auto-build enabled in builder, you will no longer see the -dev suffix denoting a pre-release build.
In addition, if you have any automation that relies on the presence of -dev in our version, that will no longer be a reliable check.
How can I tell if I’m using an unreleased artifact?
We will continue to announce our releases on both the Habitat Forum and the Chef Forum. If you need to wrap some automation around the check, you can use one of the following API endpoints to query Builder:
# List the channels a specific release is in:
# https://bldr.habitat.sh/v1/depot/pkgs/core/{pkg}/{version}/{release}/channels
# Example for the core/hab/0.88.0/20191009204957 package
> curl https://bldr.habitat.sh/v1/depot/pkgs/core/hab/0.88.0/20191009204957/channels
["unstable","stable","current","builder-live","builder-acceptance","acceptance"]
Why are we making this change?
Maintaining the -dev suffix required manual action every time we wanted to do a release, which was less than ideal for automation software! With a constantly incrementing patch version, we can now treat builds from every merge to master as a potentially releasable set of artifacts.
This is a vast improvement over our previous method, which involved pausing merges while we built a set of release candidates, validated them, and promoted them. Rather than releases being “stop the world” events, the process is now continuous and more automated. In turn, this will make it easier to ship features to users, and to ship them more frequently.
As always, thank you for using Habitat!