A couple of years ago, the maintainer of most of the Opscode-curated cookbooks wrote up a blog [1] on a workflow tool I had written, to his specification. (currently unmaintained)
He had adopted an Odd-Numbered Release versioning method, common in the Linux Kernel [2] to denote what is 'stable' and what is in development.
This was a good approach, when applied unilaterally and mentioned LOUDLY, especially since the cookbook artifacts do not provide any method for version identifiers beyond X.Y.Z - other packaging systems struggle with more identifiers and their comparison, it's a hard problem to solve when not every tool in the ecosystem speaks the same version language.
At that time, it was very clear what versions were 'stable' and what were not. If you look at a cookbook like nginx [3], and see the 'Versions' dropdown, you will see that only even-numbered artifacts have been uploaded as "releases".
In many open source projects, you may see the following behavior:
- release version 1.0.0
- bump version for development to 1.1.0.dev
(or similar)
This allows users to opt-in to the 'bleeding edge' code, i.e. "This is not stable, it may eat your servers!".
Versions have been a long-running painful discussion throughout Chef ecosystem. It's a topic that comes up all the time.
As the maintainer of Stove, Seth is the one driving the vision behind it - and as such has explained his reasoning for removal of that flag from the tool in his email above.
I don't think it maps to the same problem that we face with open source code and development versions of cookbooks, but that's his choice, and we can disagree - that's the best part of Open Source - I can fork his code and rename to to be "dutch-oven" if I want to. :)
Hope this provides some background on the 'devodd' term that I invented/introduced into Chef-land in 2012.
Best,
-M