[chef] Re: Re: Re: Versioning forked cookbooks

[Ranjib Dey < >]

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 < " target="_blank"> > 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" < " target="_blank"> > 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 < " target="_blank"> > 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