Impending foodcritic v5.0.0 release

Heads up that I’ll be releasing foodcritic 5.0.0 today sometime after
lunch (US/Pacific)

The ChangeLog is here:

Note that per the deciderating at the community meeting today that FC054
will be reverted again before release and included in a later release
after we can support optional foodcritic rules better (
https://github.com/acrmp/foodcritic/pull/358#issuecomment-141147044 ).
This has not been done yet and is also an after-lunch item to do.

The reason for the 5.0.0 major version release is dropping support of
ruby 1.9.3. This is because foodcritic needs Chef-12 to test against
and Chef-12 has dropped support for ruby 1.9.3, so ruby 1.9.3 had to be
removed from the travis matrix. Since we no longer test against 1.9.3
we cannot guarantee that it works against 1.9.3 so it was dropped in the
foodcritic.gemspec as well:


This may affect users of Chef 11.x on old rubies and old rubygems. Users
on omnibus chef 11.18.12 use ruby 1.9.3 with a recent enough rubygems
(the last 2.1.x that we can upgrade chef-11 users to before native gem
installs suffer a breakage) will simply see that ‘gem install
foodcritic’ will remove 5.0.0 from the solution set and install 4.0.0
and they will be pinned to that version–nothing should change for
them. Users which are on ruby 1.9.3 and on very old rubygems (certainly
1.8.24 is buggy this way) and which do not use a Gemfile.lock or other
explicit pin to 4.0.0 will see that it attempts to install v5.0.0 and
will fail as soon as the gem goes live – unfortunately there’s no way
to mitigate that breakage. Users need to upgrade chef and/or upgrade
ruby and/or upgrade rubygems and/or pin with a Gemfile.lock and/or pin
with a semver ~> 4.0 in your Gemfile/gemspec (and certainly those last
two are always considered best practice and everyone /should/ be doing
one of them in order to avoid any breakage).

The biggest reason to upgrade to 5.0.0 is most likely that FC009 has
been updated with up-to-date 12.4.1 and 11.18.x DSL metadata and the
node.force_override/force_default bug has been fixed so that FC009
should be substantially more accurate and useful now.

And foodcritic 5.0.0 should be live now.

On 09/17/2015 12:23 PM, Lamont Granquist wrote:

Heads up that I’ll be releasing foodcritic 5.0.0 today sometime after
lunch (US/Pacific)

The ChangeLog is here:

https://github.com/acrmp/foodcritic/blob/master/CHANGELOG.md

Note that per the deciderating at the community meeting today that
FC054 will be reverted again before release and included in a later
release after we can support optional foodcritic rules better (
https://github.com/acrmp/foodcritic/pull/358#issuecomment-141147044
). This has not been done yet and is also an after-lunch item to do.

The reason for the 5.0.0 major version release is dropping support of
ruby 1.9.3. This is because foodcritic needs Chef-12 to test against
and Chef-12 has dropped support for ruby 1.9.3, so ruby 1.9.3 had to
be removed from the travis matrix. Since we no longer test against
1.9.3 we cannot guarantee that it works against 1.9.3 so it was
dropped in the foodcritic.gemspec as well:

https://github.com/acrmp/foodcritic/pull/315
https://github.com/acrmp/foodcritic/pull/377

This may affect users of Chef 11.x on old rubies and old rubygems.
Users on omnibus chef 11.18.12 use ruby 1.9.3 with a recent enough
rubygems (the last 2.1.x that we can upgrade chef-11 users to before
native gem installs suffer a breakage) will simply see that ‘gem
install foodcritic’ will remove 5.0.0 from the solution set and
install 4.0.0 and they will be pinned to that version–nothing should
change for them. Users which are on ruby 1.9.3 and on very old
rubygems (certainly 1.8.24 is buggy this way) and which do not use a
Gemfile.lock or other explicit pin to 4.0.0 will see that it attempts
to install v5.0.0 and will fail as soon as the gem goes live –
unfortunately there’s no way to mitigate that breakage. Users need to
upgrade chef and/or upgrade ruby and/or upgrade rubygems and/or pin
with a Gemfile.lock and/or pin with a semver ~> 4.0 in your
Gemfile/gemspec (and certainly those last two are always considered
best practice and everyone /should/ be doing one of them in order to
avoid any breakage).

The biggest reason to upgrade to 5.0.0 is most likely that FC009 has
been updated with up-to-date 12.4.1 and 11.18.x DSL metadata and the
node.force_override/force_default bug has been fixed so that FC009
should be substantially more accurate and useful now.