Pascal Costanza wrote:
There are two elements being proposed: (a) having something like :cdr-nnn in *features*, and (b) having a standard package naming mechanism. One suggestion actually was to have :cdr-nnn also as a package name.
One more thing to consider is that it may not necessarily be a good thing to have the implemented CDRs active by default. For instance, I would like to be able to (require :cdr-nnn) when I want one, but also be able to live without it if I want to. If that were possible, I think the whole discussion on #; could just go away ;-)
There is indeed no way to figure out which CDR is an update to which other CDR. My opinion is that this should be kept like this. There could be situations where different people have different views on whether a particular CDR is an improvement on a previous one or not, and there shouldn't be a mechanism in place that can be abused in any way for political reasons. Just my 0.02€. ;)
Okay, so s/update to/based on/. Regardless of any judgment of value, I still think it would be useful to have a tree (graph?) view on the available CDRs, their update/fork/merge/dependency/younameit history.
Maybe a denotation mechanism is not needed. Every CDR can perfectly state that it considers itself as a followup, update or whatever else to another another one. Every CDR can also perfectly state that some others are required for it to work. But if the whole CDR thing is to grow, I fear that the situation could become messy. The point is just to make that kind of information easier to get; not to force any particular usage of it.
In practice, nothing prevents you from writing "this CDR is considered an improvement over CDR #". But nothing prevents you from completely disregarding that statement either :-)