[chef-dev] Re: Accepted RFCs for October 15th

[Noah Kantrowitz < >]

On Oct 16, 2014, at 7:34 AM, Mike 
<
 >
 wrote:

> Thanks Noah for the summaries!
> 
> > ## RFC 26: Remove HTTP Config Files
> >
> > https://github.com/opscode/chef-rfc/blob/master/rfc026-remove-http-config-files.md
> > 
> > This deprecates a relatively unknown feature whereby chef-client can 
> > download its configuration directly from an HTTP server. Given how little 
> > this feature is believed to be used, an aggressive deprecation schedule 
> > will be used such that the feature will throw a warning in future Chef 11 
> > versions and be entirely removed in Chef 12.
> 
> Sorry I missed the discussion on this particular RFC on chef-rfc repo, and 
> am unsure how to continue discussion on an already-accepted RFC - is that 
> detailed somewhere?
> 
> One point I'd like to ask about here is the "warning and deprecation" model 
> - it appears that this is going to be removed completely in Chef 12, and a 
> deprecation warning will be added to Chef 11.
> I've seen mention that there may not be any further Chef 11.x releases 
> until Chef 12 is out, which actually makes the deprecation warning a little 
> "too late" for anyone looking to upgrade and retain functionality.
> 
> Now, I don't think this is The Most Important Feature that is likely to 
> cause massive breakage for users, but it does surface the need to describe 
> a clear deprecation methodology for anything that is going to be changed 
> significantly in Chef 12 and onwards.
> 
> RFC015 [1] does a good job of defining a few of changes that are not 
> backwards compatible, but I don't believe there's any mention of adding 
> deprecation warnings in current Chef 11 for users of these features/code 
> paths.
> 
> From SemVer doc [2]:
> 
> | How should I handle deprecating functionality?
> | Deprecating existing functionality is a normal part of software 
> development and is often required to make forward progress. When you 
> deprecate part of your public API, you should do two things: (1) update 
> your documentation to let users know about the change, (2) issue a new 
> minor release with the deprecation in place. Before you completely remove 
> the functionality in a new major release there should be at least one minor 
> release that contains the deprecation so that users can smoothly transition 
> to the new API.
> 
> So it seems that the first part about updating documentation is happening 
> now, as well as will most likely be in the Chef 12 release notes, but the 
> second part about issuing a minor release of Chef 11 with deprecation 
> warnings (and any cookbooks that have deprecated code) should happen before 
> the Chef 12 release.

This is why I specifically called it out as an aggressive removal. Given how 
few people knew this feature existed, and how easy the workaround is, the 
conclusion was that going faster than SemVer recommends was okay in this 
instance. The resulting cleanup in the config code is substantial enough to 
warrant it in my opinion. No code has been merged yet though, so if you think 
this is a mistake I would start a new ML thread (just for visibility) :)

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail