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
