I’m afraid that there are too many options and too many practices. Since there are only 3 fields for release numbers, there is no option to have a “1.0.0.1” for a locally modified version of the upstream 1.0.0. And when you modify version “1.0.0” for a local patch, and call it “1.0.1” to get it to auto-update, you now have a conflict.
Personally, I like being a dirty rotten scoundrel and back numbering my in-house version of a cookbook, to say “0.9.0”. Leave space for a few revisions, and lock the version of the cookbook in the environments. Then upstream updates can be published and upated as desired without modifying the in-house verson. And when upstream gets the patches, just release the lock.
If you have to keep both cookbooks alongside each other, neither librarian-chef nor Berkshelf support deploying multiple versions of the same cookbook from the same ‘Berksfile.lock’ or ‘Cheffile.lock’. You need a different directory with a different Berksfile or a different Cheffile with the old version locked in, deploying only the relevant older cookbook and older dependencies. But this is true for any chef environment that serves multiple cookbook versions for multiple QA or Production environments from the same server.
You cannot rely on “Oh, I installed that before with Berkshelf or Libratian-chef so it will always be there.”, not unless you have a very thorough backup and lockdown system. It’s too easy to have a cookbook that conflicts in number with a new, desired upstream if you just increment numbers, and then you’re stick trying to support two cookbooks with the same name and the same number!
–
Nico Kadel-Garcia
Senior Systems Consultant
Email: nkadelgarcia-consultant@scholastic.com
Cell Phone: +1.339.368.2428
From: Ranjib Dey dey.ranjib@gmail.com
Sent: Friday, August 08, 2014 3:45 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Versioning forked cookbooks
oh, we dont upload multiple versions of same cookbooks (neither do we lock any cookbook version, since theres no 2 copies). I guess, you can either tell berks not to freeze it, or bump up version (1.4.2) in your fork. I like the second approach, but this will require you to explicitly delete the cookbook when you change you berkfile to point to upstream again
On Fri, Aug 8, 2014 at 12:39 PM, Andrew Brown <anbrown@blackberry.commailto:anbrown@blackberry.com> wrote:
We’re using berks as well, which is why the problem arrives. 
For example, berks uploads my forked cron 1.4.1 to my chef server, and then freezes it.
Community also releases cron 1.4.1, and then I revert my Berksfile change to use metadata again.
The next time Berkshelf runs, the community upload of 1.4.1 fails, as it is already frozen in my Chef server.
Cheers,
Andrew
On 2014-08-08, 3:34 PM, “Ranjib Dey” <dey.ranjib@gmail.commailto:dey.ranjib@gmail.com> wrote:
generally, we use librarian (or berks) to manage the community cookbooks, and point it to our forked repo till the patch is being merged and revert back to the upstream version when its available. This same workflow as any other rubygem + bundler
regards
ranjib
On Fri, Aug 8, 2014 at 12:18 PM, Andrew Brown <anbrown@blackberry.commailto:anbrown@blackberry.com> wrote:
Ohai Chefs,
I have a question about how to version forked community cookbooks. In our environment, we require a patch to the cron community cookbook, since it doesn’t exactly meet our needs. Since a patch has also been submitted to upstream, eventually the community version will increase its version, possibly conflicting with ours. As well, at some point in the future, we would like to switch back to the community version once the patch is accepted.
Given this background, how would you suggest to version the cron cookbook, as well as cookbooks that include it as a dependency?
Thanks!
Andrew
