On Thursday, April 21, 2011 at 1:49 AM, Hedge Hog wrote:
I’d appreciate it opscode can confirm that in their cookbooks repo,
they bump any of the major or minor or patch version numbers of any
affected cookbook when they release a Chef version?
It depends on whether particular cookbooks need to be modified for a particular Chef release. We’re pretty happy overall with the Recipe DSL, so it doesn’t (hasn’t?) changed in a way that really needs recipe refactoring, and most of the cookbooks we publish just have recipes. When updates to cookbooks occur from tickets, or work we’ve done with clients or helping users, we release new versions on the Community site.
Sometimes behavior is deprecated, such as the removal of the “@node” notation, or the meta-parameter “notifies” usage. We update cookbooks for those, and try and lag a bit on the time between the releases, but there hasn’t been a very formal release or version management. I’ve tried to make sure and mention versions of Chef required where applicable in the README.
That said, we do have a number of changes that will be coming along with the 0.10.0 release. I have another post for the mailing lists coming next week to describe a number of the changes the 0.10.rc.0 branch is going to introduce, so stay tuned.
with the version in the metadata.json (creating/updating the
metadata.json as required).
I’m wondering if there is some assurance that, for example, v0.6.2 of
zenoss will always point to the cookbook as it was when Chef was at
Or, in other words, is it possible that when the changes in the
Cookbooks 0.10.rc.0 branch get merged into master, that an affected
cookbook metadata version number does not get bumped?
As Matt mentioned, a chef_version in metadata may be useful for this, if nothing else to indicate which version of Chef to use when browsing the Community site for cookbooks - and exposing that information when using knife cookbook site commands.
We definitely recommend that folks obtain the cookbooks from the Community site, rather than using the GitHub repository. There are a number of reasons for this, least of which is version management, but also discoverability - it can be really hard to find cookbooks on GitHub since there’s so many forks. Also, it is easier to lock into a version, especially with the upcoming "Environments"1 and “Cookbook Version Constraints” features in Chef 0.10. We’ll probably tag the repository with something related to 0.9 before merging the 0.10 branch.
Joshua Timberman, Director of Training and Services
IRC, Skype, Twitter, Github: jtimberman