Pro-protocol transparency

TD supports quite a few professional, expensive technologies, like vioso, scalable, blacktrax, leuze, hokuyo, posistage etc. This can lead to users buying/advising on investment of these technologies, expecting OOB, up to date or fully featured functionality when it may not be the case. Incomplete or out of date support is fine, but this can be career destroying for people who assume full support and buy in.
Can I recommend some clear documentation on when some of these things were last developed, their last known compatible versions, explicit features to expect etc?

This kind of hooks in to my conversations on the discord about not knowing exactly which features are in official vs experimental, because they develop on two separate paths and it’s not clear which features are ported to each other once they diverge by more than one version number. This would have to be addressed at the Release level - so maybe each release could have an autogenerated wiki page with features, software/hardware SDK and version numbers, and notes of any available/ unavailable features?

+1 to both - this kind of transparency is key for pro use and is just good practice … it can be difficult to track this stuff down on a short timetable, which is often the ask when putting together proposals or pitches in a pro context.

The experimental always has all the features the Official has. So to see what the experimental has you just need to look at it’s release notes. Same is true for the official. Maybe you are asking for something else though? Please elaborate if so.

@jmt4zj As Malcolm said, but also so you understand, the branches are completely separate. There is no transfer of features from Experimental into Official, no ‘cherry-picking’ as it’s sometimes called. The complete experimental branch will be promoted to Official status when it is ready, we do not move one feature over at a time.

1 Like