Re: XEmacs package code

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Kai" == Kai Großjohann <address@hidden> writes:

Kai> address@hidden (Michael Sperber [Mr.  Preprocessor]) writes:

>> So we really need an infrastructure that deals with versioning and
>> allows you to express requirements like "version x of package z" or
>> "any version after x of package z" or "any version of package z
>> between x and y" and so on.

Kai> There are Emacs developers who feel that this is not the right
Kai> answer.  Instead of requiring a specific version, one should look for
Kai> the features supported by that version and require those, instead.

Kai> My humble opinion is that one should look for the features whenever
Kai> feasible, but sometimes it might not be feasible to do that.  

In fact, it is quite often not feasible to do that: package evoluation
very often does not happen in terms of features provided.  Instead, it
often happens in terms of bug fixing or an evolving API.  Moreover,
you learn about features only *after* you've loaded the package.  This
is usually too late in an environment where multiple versions of a
single package can coexist.  Also, this is much too hard for users to
deal with who really want to say "This version and no others."

Of course, some of that can be fixed.  But the present provide/require
machinery is way too coarse for it.  And are you really willing to
provide features like "recompile-wrong-buffer-bug-fixed"?  Or
"find-file-takes-2-arguments"?

Of course there are many configuration questions you *can* attach to
features, and my design draft specifically accounts for those.  But
there's no way it can solve all or even most of the problems
associated with configuration management in the face of the situation
I envision.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla