The vague solution is that we'll have some sort of package of metadata
file on the CPAN or in the index somewhere.
This package will contain, describe, or evaluate some set of critical
minimum requirements.
The clients will check with this metadata/file/package/code to see if
they are fatally out of date.
Note I refer to "fatally". I don't think this is something we'd use to
push general upgrades along, but it's something we'd use if we hit a
genuinely fatal toolchain failure of some sort, that can't be recovered
any other way and for which we'd rather NOT have legacy versions try to
continue, without updating themselves first.
I'm not sure on the specifics yet, but the communication should almost
certainly be between the CPAN client and the repository it is connecting to.
Adam K
Eric Wilhelm wrote:
# from Adam Kennedy
# on Tuesday 24 July 2007 04:40 pm:
Eric Wilhelm wrote:
I was thinking it would be a good idea to list outdated CPAN(PLUS)
as conflicts using '>=' versions in META.yml. Probably by default.
Conflicts implies a fatal package clash for this one specific module.
You're right, it was just a thought.
If CPAN(PLUS) is fatally out of date for a significant subset of CPAN,
we need to deal with that seperately, without duplicate a ton of
metadata in the META.yml.
Also, CPAN(PLUS) is (should be) entirely outside the concern of the
configuration script/phase.
The CPAN client is a layer ABOVE the configure script.
Yes, but we need *some* mechanism for saying "if you're using a client,
it must be able to support installing this module."
What about using the META.yml version number as a compatibility key?
Or, having something in META.yml such as "client_support_version"?
This (of course) doesn't work on the legacy clients, but that's not the
goal here. I'm simply looking for some way to cue clients to update
themselves, which of course requires a self-updating client. (Assuming
that not all clients are "aggressively self-updating", since there
seems to be some resistance to that.)
--Eric
