To coincide with the new launch of Supermarket, I’m excited to announce Stove v3.0.0 has landed in your Kitchen. It’s bright, shiny, stainless steel, and uses the latest convection cooking technologies for ultimate pleasure.
Stove 3.0 includes a number of important changes:
Publish to Supermarket by default
Added support for signed tags (thanks Noah!)
Require Ruby 1.9+
Remove a bunch of dependencies (i18n, mixlib-authentication, solve, octokit, jiralicious, faraday, and more)
Remove GitHub functionality (you can still push git tags, but not artifacts)
Remove JIRA functionality (JIRA IS DEAD!)
Remove bump functionality
Remove devodd functionality
There are also a number of bug fixes:
Clarify use of Gemfile vs non-Gemfile
Always read cookbooks as binary objects
Ensure tempfiles are written with the proper mime_type
Do not package editor files
Frequently Asked Questions
Q: Why did you remove bump functionality?
A: You, as a cookbook maintainer, should make an intelligent decision about the version you wish to create. You should version and commit that change as part of your workflow.
Q: Why did you remove the devodd functionality?
A: Before a land of Test Kitchen and Chef Zero, you would often test a cookbook by uploading to a production Chef Server and running some tests. Those days are gone. I have never been a fan of devodd, and I cannot continue to encourage its use by making it a part of a tool I manufacture. Stop doing devodd. Stop uploading unreleased artifacts to your Chef Servers :).
Q: Why did you remove the GitHub artifacts?
A: There are actually a few reasons: First, and most importantly, GitHub has changed their releases API on more than one occasion. Second, it is an incredibly expensive operation - requiring multiple HTTP requests. The “slowness” often experienced was due to the multiple roundtrips required to push an artifact as a “release” to GitHub. Third, I believe Stove should support git, not a third-party hosting provider. I do not wish to propagate the notion that GitHub is a required part of the Chef toolchain. Fourth, in order to better track downloads and usage, you should download cookbooks from an authoritative source.
Q: Why did you remove the JIRA functionality?
A: Didn’t you hear? JIRA is dead! In all actuality, the JIRA functionality was a Chef/Opscode-specific thing. It was really selfish of me to include in Stove, and probably never should have been there in the first place.
Q: Why did you require Ruby 1.9+?
A: Because Ruby 1.8 is dead. Omnibus is 1.9. ChefDK is 2.1.
Q: Why did you remove all those dependencies?
A: There was some controversy over using Stove as a dependency in a project. By minimizing the number of dependencies, it is now again possible to use Stove in your Gemfile. I’ve update the documentation and examples as such.
Q: Can I share with my behind-the-firewall solution?
A: If you are running a behind-the-firewall solution (such as Supermarket), that follows the cookbooks API and mixlib-authentication signed header auth schema, it will continue to work with the new stove.
Q: Is it faster?
A: Yes, like 50x faster