You wrote:
> "Eric M. Ludlam" <eric@...> writes:
> >>>> Alex Schroeder <alex@...> seems to think that:
> >>"Eric M. Ludlam" <eric@...> writes:
> >>
> >>> That is a good idea that had come up recently. I am hoping to do
> >>> this in the future.
> >>
> >>The simple thing would be to just provide more features:
> >>
> >>(provide 'eieio)
> >>(provide 'eieio-2.0)
> >>(provide 'eieio-2.1)
> >>(provide 'eieio-2.2)
> >>(provide 'eieio-2.3)
> >>
> >>And then other code could test this:
> >>
> >>(require 'eieio-2.2)
> >
> > I think that might be:
> >
> > (require 'eieio-2.2 "eieio")
> >
> > but I get the idea. I can just see a list of about 100 releases 10
> > years from now. ;)
> IMO, this is requiring too much manual effort, and would not fit too well
> for code changes between release cycles (since you might be hesitant to
> make a new version). One approach I can imagine would be to put the RCS
> Id into a variable and do a substring match on it. That would only make
> it one file to change by hand, and allows a nice, custom error message.
A suggestion is to include a function in EIEIO (and all other packages) tha=
t tests if this version of EIEIO is compatible with the version number supp=
lied as argument. For example in EIEIO you define:
(defun eieio-ensure-compatibility (major minor)=20
(cond=20
((> major eieio-version-major) (error "You must upgrade EIEIO to a new=
version!"))
((< major 2) (error "Your EIEIO version is too new :-)!"))))
And in the package that uses EIEIO you write:
(require 'eieio)
(eieio-ensure-compatibility 2 3) ;; Here you put the version of EIEIO you h=
ave tested with
/Jesper Nordenberg
|