Wolfgang Grandegger wrote:
> Hi Jan,
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Hi Jan,
>>> currently the RT-Socket-CAN drivers maintains it's own version or
>>> release number. As RT-Socket-CAN is part of Xenomai, I do not see the
>>> need for it (and so far I did not update it). What is the intended use
>>> of "driver_version" in "struct rtdm_device"?
>> Actually, I was thinking about this too yesterday. The idea of the
>> separate versioning for RTDM drivers is to signal the users if something
>> in the driver really changed. It's fairly obvious what to do with it for
>> out-of-tree drivers, but for in-tree it might be worth considering the
>> policy.
>> The current model, maintained more or less properly for the existing
>> drivers, is to increment independently of Xenomai according to major or
>> minor changes. One may ease this burden for the driver developer by
>> simply filling in Xenomai's version here. That would just let the
>> revisions increase on every Xenomai release, even if the driver remained
>> untouched. The tag would still have a meaning for out-of-tree drivers,
>> but for in-tree it would be fairly meaningless.
>> Well, whatever is commonly preferred, it should then be applied
>> consistently on all RTDM drivers in Xenomai. What are the opinions on
>> this list (I will comment afterwards)?
> OK, no other opinions so far. Then let's keep the current versioning

I guess everyone's busy with more serious issues.

> scheme. I'm going to boost the RT-Socket-CAN version number to 0.90.0
> with the next commit and to 1.0.0 for the next official release (2.4.x?).

Ack. That's preferred from my side as well.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to