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

[Mike < >]

This is currently an unsolved problem.

There's a lot of contention around versioning and Chef, and there's no clear workflow for "what works best".

The flow Ranjib mentioned is one we do as well, and we don't freeze cookbooks on upload for this reason.

Is it perfect? Nope. But it works for now, at least until we can introduce better version identifiers in to Chef, chef-client, knife, and any plugins that we leverage for that to speak the same versioning language.

-M

On Fri, Aug 8, 2014 at 3: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