On 03/12/2016 22:56, Laurie, VK3AMA wrote: > I understand, especially about Git commit strings, eg. from one of my > repositories... "d79c7aa89d8b643ddc43a8f5dbed9b0f4dae22e7". > > What is needed is some way to uniquely identify the version/build > being used. An auto-incrementing integer would probably be the best as > it would make the code check trivial. > > IMO, if it is important enough to have the version number in the > window title and the build number in the "About" window to uniquely > identify to the end-user which version/build they are running, then > someway to expose this uniqueness in a UDP message needs also to be > available.
Hi Laurie, Mike & all, I propose adding the WSJT-X version and revision to the UDP heartbeat message. I choose these two fields because they already have functions to create them and are used for generating the title bars and about box contents. The version is M.m.patch where M is the major version number, m is minor version number and p is the patch which is a number in GA releases and a number plus -rcN for release candidates. The revision is derived from the source control system and current is a Subversion change list number possibly followed by -dirty if there are local edits. Note that the revision cannot be relied upon since applications built from a source archive rather than directly from source control will not have a revision. If we were to move to git then I would expect the normal convention, of using only the first five digits of the revision SHA to signify a revision, to be adopted. I am proposing to add these two utf8 strings to the heartbeat message as there seems little point adding them to every status message, especially as they are already quite long for UDP messages. The heartbeat message should be the first message processed by any server so seems a natural place to process this sort of information. As the heartbeat message is bidirectional, servers may choose to also populate these two fields with meaningful information conceptually the same as version and revision. These values will not currently be used by WSJT-X but may prove useful in future. Obviously if further fields are added to the heartbeat message the servers must provide these new fields if they need to send any other new field yet to be specified. Empty fields sill be acceptable. 73 Bill G4WJS. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel