# from Michael G Schwern
# on Friday 21 December 2007 19:59:
>version: 2.01
>api_version: 2.0
>api_compatibility: 1.4
>stability: high
>release_type: bugfix
>
>What this would communicate is that this is version 2.01, a bugfix
> release. It implements the same API as version 2.0. It's backwards
> compatible to version 1.4. The author considers it very stable.
Is that "API stable" or "no major bugs" stable?
How high is "high"? What's above "high"? ("phenomenal"?) Qualitative
stuff is difficult to make consistent -- what do we gain from having a
non-binding qualitative statement in this data file? Would a new
maintainer be held to this promise if they considered the old API
buggy/ambiguous?
I'm also not sure about the release_type. That sounds like changelog
data. The api_compatibility and api_version sound good, but thinking
ahead they also sound like changelog data. Given the distinction
between "api" and "release" appearing in this new sort of meta.yml, how
do I know what "api version" I was running before?
Given the recent discussion of a machine-readable changelog, I'm
actually thinking all of the above-listed fields belong (at least
canonically -- from the author's POV) in the changelog.
Well, version is a bit different -- that needs a machine-writable
changelog.
Given the absence of a version-pegging include() statement, most of this
information's usefulness is in the human-readable sector. Though it
does have other uses if the installer can figure out a way to resolve
dependencies without breaking your site's "needs compatibility
with ..." assertions.
--Eric
--
"It is a mistake to allow any mechanical object to realize that you are
in a hurry."
--Ralph's Observation
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
