IMO coding the version into the cookbook is anti-pattern, as this is
what attributes are for. In general on internal cookbooks I start
with that cookbook designed for whatever is currently being deployed.
Over time that may change and we will add support for the newer
version of whatever package.
That being said. I haven’t really ever thought about encoding a
version into the recipe name, but if I did i would probably do it like
I would still use attributes to drive which version, but now you have
a clean layout to handle all your versions and common bits. I can see
a benefit to breaking large cookbooks up this way, but that benefit is
for the maintainer(s).
On Wed, Oct 17, 2012 at 11:56 AM, Peter Donald firstname.lastname@example.org wrote:
Mostly we try to support multiple versions of a product through a single
version of a cookbook. That way we can have the same cookbook deployed
across dev/uat/staging/production but have different product versions in
each environment. We have cases where there is differences in the install
between different versions of the product we will often have a sprinkling of
if’s in the cookbook ala;
if node[‘product’][‘version’] > ‘1.0’
Do 1.0 magic
Do pre 1.0 magic
The main reason we do this is we can decouple the release process from the
process that uploads/promotes cookbooks.
On Thu, Oct 18, 2012 at 1:30 AM, email@example.com wrote:
We have come across this design pattern many times when building out our
cookbooks and can’t quite decide which makes the most sense. Do you write
cookbook such that the latest version of the cookbook can install any
of the application it is installing/configuring or do you create separate
versions of the cookbook for each version of the cookbook (i.e. each
version installs only one version of the software)? The Opscode cookbooks
to go with the first strategy but we have found we can make simpler
by going with the second strategy.