[chef] Vesion Contraints

[JayP < >]

Ohai Chefs!

I was wondering if anyone has come up with a good rule to follow for managing
version constraints.  There are several places to declare version constraints
and doing some research I have found a few candidates that allow flexibility
but I still worry there may be conflicts when chef goes to run on a host.  The
approach I plan to take goes as follows:

The cookbook pattern names I use below were pulled from a presentation by Tom
Duffield at a Chef Meetup
(https://tomduffield.com/everything-as-a-cookbook-devops-minneapolis-meetup/)
in case you need more context as to what type of cookbook I am talking about.

The locations listed below will state what type of version constriant is used
on a particular cookbook

Environment Files:
Only Application cookbooks are locked here using the '=' operator.

Application/Role Cookbook:
Either Platform or Infrastructure Cookbooks are dependencies in the 
metadata.rb
and use the pessimistic constraint: ~> 1.0.0 (which means it can use all
version upto but not including 1.1.0)

Platform Cookbook:
Infrastructure cookbooks can be dependencies but a pessimistic constraint ~>
1.0.0 (All bug fixes are taken) is used in the metadata file.

Infrastructure Cookbook:
Usually these don't have any dependencies so version constraints shouldn't be 
a
problem here.

Wrapper Cookbook:
Falls into the same category as the cookbook it is wrapping and the dependency
should only be the cookbook it wraps.  I would think these use the pessimistic
operator but only lock to minor versions so ~> 1.0 (all minor versions are
taken).  If it needs to add another dependency on another cookbook it would
then use ~ 1.0.0 (always take bug fixes)

Based on the cookbook types and how versions are locked in each does this 
sound
good to anyone?  Do you see a lot of flaws with this approach?  Any other
suggestions on a better approach?  

My biggest concern would probably be our base cookbook that defines how we 
want
all our servers to be configured at the bare minimum.  This cookbook has
basically replaced our base role cookbook so it defines a full run list with
several depends.  We could lock the base cookbook at the environment level but
all the dependencies this cookbook has could possibly cause version constraint
failures because of it's broad reach.  Any one else have this issue?

To iterate we want the flexibility to allow one team to use say one version of
the mongodb cookbook and another to use say a newer version.  We would prefer
not to force major cookbook versions onto teams and allow them to upgrade at
their convenience.  Currently we are locking everything in the production
environment file and it has been a real pain and would prefer to be more
flexible with cookbook version use.

Thanks for any help!

- Jay