Eric Wilhelm wrote:
>> 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?
I was thinking "no major bugs" stable. API stability is implicit in the
statement of backwards compatibility and release type... maybe. Point is, the
two concepts are separate.
> 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?
It's the programatic equivalent of asking the author and it's about the best
you can hope for. It doesn't need to be particularly accurate or finely
grained. Just enough to get a feel for "is it safe to install this"? It
might be as simple as "experimental" vs "release" qualities which would
replace the X.YY_ZZ alpha version convention.
Or there's Debian's tiers of "experimental", "unstable", "testing" and "stable".
It's also possible that "release_type" and "stability" are really saying
basically the same things.
> 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?
Good point. Fortunately, as a protocol, META.yml doesn't have to worry about
that. :) Possible implementations include installation storing the META.yml
(which would be on the way to a catalog of installed modules) or simply asking
a web service.
> 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.
Fortunately the information for the META.yml can come from anywhere. But we
don't want to get into scattering module info all over the place, that's what
META.yml is meant to replace. Also we control the META.yml but authors can
get very picky about their changelog formatting and will probably take a lot
longer to adopt it.
> Given the absence of a version-pegging include() statement
http://search.cpan.org/dist/only/
> 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.
I think it will be handy for CPAN to generate alternative indexes listing the
latest experimental, unstable, testing and stable releases a la Debian.
--
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in <[EMAIL PROTECTED]>
