Chef and ChefDK version number changes

Chef Infra (archive)
1

Hi Chefs!

Starting today, you may notice that part of the chef and chefdk version numbers are much larger than they typically have been. Additionally, you will no longer see build timestamps (like 12.8.1+239875298752) in the version number in the current channel.

This requires no action on your part, and won’t affect most people–just note that the next stable version of Chef could be 12.9.5612 :). This change comes from the community RFC #47 (https://github.com/chef/chef-rfc/blob/master/rfc047-release-process.md#continuous-integration--continuous-delivery-build-system), and is part of an effort that will lead to more reliable, frequent releases of chef and chefdk. Read on past the fold if you want more details.

– the fold –

Up to this point, Chef’s version has generally remained untouched during development between releases. As a consequence, in order for each build version to be unique, the builds we published publicly to our current channel had to include a pesky date/timestamp embedded in the build number.

Now, we are switching to real, unique build numbers with auto-incrementing patch versions for each build (12.9.1, 12.9.2, 12.9.3). Major and minor version bumps will work like they currently do–there are no changes there. This has two main benefits:

  1. Faster, more stable releases: Instead of producing a new set of binary packages each time we want to release (so that it has a clean version number), and restarting testing anew, we can promote packages from the current channel that’ve already been battle-hardened. This means less delay getting a release out, and it means using builds that have already been in the wild, which is a win for everyone!

  2. Software that doesn’t work with package names like chef-12.8.0+2398723895724-1-x86.rpm will now be able to use current channel builds.

Because of this, the stable version of chef we choose to promote could be any patch version (like 12.9.180). No other builds will be in the stable channel, so people picking up stable releases won’t see 12.9.1, 12.9.2, etc., just the released one. We hope the benefits will outweigh the confusion this could cause (“where is 12.9.1?”).

How it works:
Each time a PR to https://github.com/chef/chef is merged, several things will happen:

  • The version bot (https://github.com/chef/lita-versioner) bumps the patch version in the Chef source.
  • A new build of all packages (.deb, .rpm, .msi, etc.) Chef supports is created and run through our tests.
  • If the tests pass, the build is put in the current channel.

This means you’ll see some commits like this show up in the log:

commit 9f7dfb63e5276c922664af513d3eb420ce1ce36d
Author: Chef Versioner <chef-versioner@chef.io>
Date:   Tue Mar 22 16:43:27 2016 +0000

    Bump version of chef to 12.8.3 by Chef Versioner.

Merging to master

This does affect how commits get pushed to Chef, especially with rebases: in order for github to recognize that a PR was closed with a merge, the commits in the branch need to match the commits in master. This means that if you rebase your branch against master before pushing, you have to force push your branch. If that sounds like nonsense to you, then you’re probably just using the Merge button in github anyway, which works fine. So don’t worry!

Let us know if any problems do occur with installation or anything else!

Thanks,

–John Keiser, Chef