I see where 1.7.0 + revision is workable.  The rcN is fairly irrelevant but can 
be ignored....as can "dirty"

So you'd end up having to parse the 3 numbers from 1.7.0 and add the revision 
and then check all 4, right?
So v1=1, v2=7, v3=0, rev=7359if (v1 >=1 && v2>=7 && v3>=0 && rev >=7358) then 
revision_is_available Bad example I know but that's the idea, right?
And I know this is futuristic....but...How would you determine an SHA value is 
greater than another SHA value?
de Mike W9MDB
      From: Bill Somerville <g4...@classdesign.com>
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Sunday, December 4, 2016 4:30 AM
 Subject: Re: [wsjt-devel] Request: Expose WSJT-X version & build numbers in 
UDP Status message
   
 On 04/12/2016 05:24, Black Michael wrote:
  
 Should be able to auto extract the revision and stick it an include file so it 
can be part of any source archive. The source archives will HAVE to produce 
this otherwise apps like JTAlert will not know what version they're talking to. 
I did that before with CVS instead of using the macros for just that reason. 
  As for git...the SHA values are useless aren't they (other than being 
unique)? How are you supposed to be able to tell what's more current without 
looking at the whole git log?  Or am I missing some magic there? Perhaps if we 
switch to git we just switch to manually incrementing the old SVN number.  It 
really doesn't have to increment with every CM update -- just being a number 
that NEVER goes backwards or changes to some funky git thing is all that's 
needed.  As long as backwards compatibility is maintained it's trivial for an 
app to say "if revision > XXXX then.... 
 Hi Mike, the information that I am calling revision, e.g. SVN change number or 
git SHA or part thereof, all suffer from the same issue in that they *do not* 
reflect the generation, in time, of a software application. This is because of 
branching in source control systems which means that a single linear 
progression is incapable of determining "maturity". Older source control 
systems like Subversion use an incrementing change number, modern distributed 
source control systems recognize that such numbers are no more that unique tags 
and any further analysis is futile in all but the most trivial code lines. For 
a concrete and very likely example, we will branch the WSJT-X code line just 
before the GA release of v1.7.0 and then do some changes to the trunk 
development branch which would be v1.8.0-rc1. At first glance the higher change 
numbers on the trunk would imply the latest functionality. That's fine until we 
find a defect in the v1.7.0 release that must be fixed by a patch release, say 
v1.7.1, which would then have a higher change number than the the trunk or any 
other branch. I understand Laurie's desire to differentiate by change number 
but I also doubt that the revision information will be helpful other than in 
isolated edge cases e.g. when a particular specific revision is known to be 
broken. You suggest that a manually generated version number be applied which 
follows a strict numeric generation. That must be capable of convening the 
complexities of branch generations. We already have exactly that in the version 
number. It is both unfortunate and useful that many testers go on air with 
pre-release revisions, this is not something we wish to control other than 
reminding users that they must build the product themselves, stay up to date, 
be systematic and responsive in reporting issues and, understand that support 
will be limited at best, especially with revisions that are stated as not yet 
fit for use on air. The same rules must also apply to users of other products 
that work with WSJT-X and are sensitive to WSJT-X functionality. We have a 
release schedule, it may be a bit slower than some desire but remember that new 
ground is being broken with each release, for example two whole new 
communication protocols (QRA64 and MSK144) in v1.7 and these facilities require 
enormous effort to even get to the initial limited capability that can be alpha 
tested on the bands let alone polished enough for general use with the 
technical support requirement that implies. 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


   
------------------------------------------------------------------------------
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

Reply via email to