[chef] Re: Re: Re: Ideas for namespacing breaking attribute changes

[Zac Stevens < >]

On Thu, Jan 23, 2014 at 9:25 PM, Daniel DeLeo < " target="_blank"> > wrote:

On Thursday, January 23, 2014 at 1:16 PM, Matt Ray wrote:

I really like the configuration option of shipping both and specifying

the one to use. Default to the old plugin, but start throwing

deprecation warnings, and then drop the old plugin in the Ohai shipped

with Chef 12? That gives people plenty of time to upgrade without

breaking anything, knowing that Chef 12 clearly will break this.

The downside is that all cookbooks have to support both, or you have to upgrade everything in lockstep. You can’t have one cookbook that only supports v1 and another cookbook that only supports v2 in the same chef run.

The backwards-incompatible version 3 update to the yum cookbook demonstrates this problem.  Restated, you can't start using the new one until you first touch everything using the old one.  This twists the experience of using the new shiny into a yak-shaving exercise.

I'm in favour of two versions of the cloud attributes existing side-by-side, the old one deprecated for a suitably long period before being removed.  I don't have a clear idea of what I think is a suitable period, though - three to six months seems reasonable, a year onerously long.  If this approach was adopted, how could the old plugin be deprecated?  The plugin could log a deprecation warning, but this doesn't help to identify anything using it.  Logging when the deprecated attributes are accessed might be nice in theory (albeit noisy), but I suspect is impractical and/or an awful idea.  Shipping Foodcritic rules to highlight deprecated usage would be a help.

Zac