Closed waynepiekarski closed 5 years ago
Another idea would be to have a separate command to ask the plugin details of it's version and supported features. That would not break backward compatibility if some client assumes "EXTPLANE 1" string. Also git commit version might be useful here.
I noticed in #11 that you have prepared a fix to set individual array values. This is great, but it would be good to know if the plugin supports this feature.
Even an incrementing integer that is bumped up every time a change like this is made, would be good. We could use an extplane-get command, or you could emit the subversion on a new line to keep it separate from the original welcome message:
EXTPLANE 1 EXTPLANE-VERSION 52
The integer would need to atomically increase each time you make a fix like this. Having the version on a new line would probably allow most existing clients to keep working.
Pull requests welcome.
Ok, great. I'll prepare in a few days some changes which will add more versioning information to the intro header so there are no extra commands. This will really be helpful for ExtPlane going forward.
I produced a pull request which adds the new EXTPLANE-VERSION header. All my existing ExtPlane apps work fine, since it doesn't change the format of any existing messages. What do you think?
Also, whenever you make a new feature or bug fix in the future, you will need to increment the constant so that clients can detect if the version they need is in use.
This should be now fixed in pr #40
Right now, when you connect to ExtPlane, you get "EXTPLANE 1" returned back. However, there have been many versions of ExtPlane, some with bugs, some with new features that are required, and it is difficult for the client to know if the plugin is up to date.
It would be good if we could have some more information included here. Perhaps a major version number (1), followed by an incrementing build id that is unique for each build, so that clients could check if expected_minor_version >= plugin_minor_version. The easiest case with no changes to the build system would be something like "EXTPLANE 1" followed by the DATE string from the compiler so we know when the plugin was compiled.
https://github.com/vranki/ExtPlane/blob/4e78771e5587b9ecefc70073ac82993af1bdc4f9/extplane-server/tcpclient.cpp#L26 Could become:
out << "EXTPLANE 1 " __DATE__ " " __TIME__ "\n";
Does anyone have any thoughts on this? I have a bunch of users with ancient buggy plugins out there, and it would be good to be able to detect this and print warning messages to get them to update.