expand release process doc post-release steps, includes pin of Chef Client

[marcparadise]

These changes to post-release process will ensure the various components
and dependencies bundled with Chef Server are kept up to date with the
latest security and bug fixes. Making these part of the post-release process
also ensures that the changes are in place before work on the new release begins,
so that we work through a full release with the updates in place.

This also locks the bundled Chef Client to the currently released stable
version at the start of development for a new release.

[stevendanna]

@smith How do you feel about this?

[marcparadise]

I think that is done implicitly with the bundle update in omnibus?

diff --git a/omnibus/Gemfile.lock b/omnibus/Gemfile.lock
index 7df82e4..745ba5b 100644
--- a/omnibus/Gemfile.lock
+++ b/omnibus/Gemfile.lock
@@ -1,16 +1,16 @@
 GIT
   remote: git://github.com/chef/omnibus-software.git
-  revision: 0428549848dec70d2c0814ba50d5d9d19f63f9d1
+  revision: df6193ea323343e6e472b8abd1b50aac3750b1e9
   specs:
     omnibus-software (4.0.0)

[stevendanna]

@marcparadise Darn I thought I had deleted my comment before you would see it. Yes, it does, I just failed to read :D :D

[stevendanna]

@chef/chef-server-maintainers Thoughts? @mmzyk Is there a github SPOOL team, this would likely affect them too.

[tylercloke]

@marcparadise Hrm, I have concerns about doing it right at release time. If we pull a bug in, we might not catch it before it goes out the door? We should consider pulling things in constantly if we are just gonna pull them all in when we release. Seems safer.

[tylercloke]

To be clear, I generally agree we should be updating our deps regularly, I just think right before we release is exactly the wrong time to do so.

[ksubrama]

Yeah, client teams moved to a model where no version bumps occur inside the omnibus software/project definitions right before a release because right before release, we kept pulling in a new bundler or rubygems or berkshelf or rubocop or something that had a regression that we then needed to patch and baby sit the builds through.

I do like the part where we do berks update/bundle update in the omnibus directory though. We do need to regularly keep up with upstream changes to software definitions. I personally prefer letting it float and constantly get updates (like automatically picking up openssl or cacert or other security updates) but pulling it before a release should work too.

[ksubrama]

Maybe this is implicit, but we should also override ohai. The default for both of these is to pull from master of chef/chef and chef/ohai and ohai has a circular dependency on the chef repo (to pull chef-config). Only during chef-client releases is there a good guarantee that all the versions agree without random duplicate gems.

[tylercloke]

I'm not actually seeing chef locked atm. Is that coming in a separate PR @marcparadise?

[stevendanna]

@chef/chef-server-maintainers Let's decide on the path forward for versioning and pinning. To me the main question is: What policy has the lowest support burden for the SPOOL team or other feature teams who need to release chef-server.

[tylercloke]

Might wanna note that people can just look on downloads.chef.io/chef-dk to see what the latest version is.

[stevendanna]

@chef/chef-server-maintainers Let's figure out what part of these updates we still want and get it merged. Personally, right now I'm feeling kinda 👎 on the automatic bundle updates and berks update until we have better testing/assurance around those components.

[stevendanna]

I'm going to close this out since the release process docs are supposed to cover the currently-followed release process and many of the edits here don't apply anymore. If we want to pursue post-release version bumping, we should look into creating an expeditor trigger for them.