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
