Cookbook support in the world of monthly releases

chef-dev
#1

As Chef has now stuck to the monthly release cadence for several months now (which is super cool :+1::+1::+1:), we have a lot more minor revs floating around than we once did. As a cookbook author, this raises the question of what versions should be supported, what versions should be tested on, and how long each of those should last for. Compounding this is the fact that Chef 13 is not yet on the horizon, so I can count on a deus ex machina to reset the clock :slight_smile:

How are others coping with this? Should we agree on some standard set of rules for “A+” community cookbooks like supporting everything in the current major release (which is what I’ve been doing but is getting unmanagable), or maybe the last N releases, or perhaps something like designating certain release to be LTS?

1 Like
#2

I’ve thought about this as well – and I’ve been doing a lot of testing against different Chef versions (and I know you’re doing that too, @coderanger). There’s enough incompatibility between minor versions of Chef 12 that I’m still testing against versions that I know had major changes, e.g. 12.4 to 12.5. I think we’re stuck until 13.x +/- some amount of time for adoption.

I like the idea of LTS Chef versions – I’d nominate 12.5.x :slight_smile:

#3

I would agree with marking certain versions as “LTS” to give the community
at large a guideline of what to test against. I have run into to many
cookbooks that only test on the newest version and don’t verify large
changes (like the provider changes in 12.5). Personally, I have tried to
keep my stuff (gluster and salt) compatible with 11.x and 12.x but that is
difficult to sustain in the long run.

-Grant