R devel - Oct 2008 - Version information for S4 classes --- elementary version management

Hi,

we are about to update some class definitions in our distrXXX family
of packages, so I would be eager to know whether there are plans
in R Core to implement some version management tools for
S4 classes as described in section 7.4 in JMC's "Green Book".
In his recent book (continuing the color scheme, is it to be called
the "Yellow Book"? :-), this topic has not been taken up again, so
we are not sure whether there still is the goal to go into this direction...

We have already implemented some "individual" sort of (class) version
management in our packages, but as this issue does not only concern
our packages, some standardized proceding would be desirable.

AFAICS, in R 2.8.0, by default when save()ing/load()ing single S4
objects, the corresponding class definitions are not saved/restored
along, while they are saved() and again restored on load() by default
when producing an image by save.image(), although an existing
class definition will not be overwritten.

So when load()ing an (old) S4 object, by default there will be no
information about the class definition at save() time available.
Of course, conceptually, such information would best be stored
in the respective classRepresentation object; however, as this one
does not get save()d automatically along with an object, we might
think of alternatives.  It might at least be a compromise to store the
some version information as a special slot to every object of
any S4 class.

For S4 classes defined in packages (which should make for 
the vast majority of them), default information could be obtained
from the package version tag in the DESCRIPTION file.
The rationale behind this is that an updated class definition would
at least be traceable to one particular package version, while
on the other hand the package version string is not a "large" object.

Based on this package version information, (elementary)
version management could then be provided by means of
generic functions

getClassVersion()  [as described in the Green Book, 7.4]
conv2NewVersion() ## by default issuing an error ("Not yet defined")
isOldVersion() ## true or false; by default NA

Defining particular methods for his classes, a package maintainer
could then issue specific warnings or --- at its best --- even
provide coercing methods.

What do you think about this?

Best, Peter