Having a version number is primarily for the benefit of the software developer. If someone submits an event with a problem, having the version number as part of that field makes it possible for the developer to know what version of the program was used, which can be helpful when trying to locate bugs.
Updating the version number for every minor change might not be necessary, but major revisions should probably be noted.
WinTD has included that since we switched to the newer spec in 2008. The actual dialog choice is “Scholastic” vs “Non-Scholastic, Not GP” vs “Grand Prix”. Those are used to fill in the s_sch_lvl and s_gr_prix fields. (A GP tournament has to be non-scholastic). I don’t think we’ve ever done the two JTP choices—I don’t recall if those were even part of the spec in 2008.
The biggest problem will be whether TD’s doing the submission even care about putting the correct information in that. Apparently, there are more than a few sections that have been coded as Grand Prix that aren’t (and aren’t even close). I guess “Grand Prix” sounds cool, so they chose that without necessarily knowing what it meant.
I doubt the 2C spec has changed in the last 15 years.
I tend to agree with you on the Grand Prix coding, and I know the office reviews every Grand Prix coded event to make sure it had a Grand Prix TLA and that the GP points match up with what was advertised in the TLA. I think they also do a check for events that should have been coded as GP but were not.
They do similar checks for FIDE events, since all FIDE events must be pre-registered with FIDE through the office. (FIDE Academy events deal directly with the FIDE office.)
Junior Grand Prix events also have to be dealt with manually, because there’s no way to programmatically check that an event met the JGP requirements.
If the JTP’s were in the original spec, I’m pretty sure I would have left them out as I didn’t want to get into questions of what exactly the rules were regarding JTP’s (and, of course, more choices can create more confusion—as in the errors with GP sections).
Makes sense to me, JTP events require extra attention by the TDs as they may have to generate IDs for new players and they need to make sure we have birthdates because the event won’t pass validation without them. So selecting one of the JTP options after the event is uploaded doesn’t strike me as a major imposition.
The only event in which I have done backroom that used JTP, it was mainly to avoid running down every last K-3 player with an expired ID, but all the players had ID’s. Does the birthdate validation apply to all players, or just the ones for whom a new ID needs to be generated? (I would have been surprised if all 150 odd players in the primary sections all had valid birthdates in the system.)
My SaaS Microsoft Word says it’s version 2404, build 17531.20152.
most SaaS apps don’t list version numbers. Chess Nut continuously deploys. There were 3 new deploys today. Unlike software that has major releases every quarter or in some cases much longer learning loops, it is not super practical for a rapidly improving platform to keep versioning.
It’s fairly easy to change 1 number per deploy and there are tools that will do that automatically for you, whether by day or by git commit hash or by some other reference.
For the purposes of the version of the program listed in the dbf files, I’d think that the only need to change version would be when that code is edited. Pretty sure mine says…“WEBTD 0.2”.
The JTP rules, which date back to around 1990, state that all players in a K-3 event must be in grade 3 or below and all players in a K-12 event must be in grade 12 or below, which is why adult house players are prohibited.
However, since we don’t have school grade information in member records, we use the birthdate as a sanity check. For K-3 JTP events, all players must be older than 2 and younger than 11, for K-12 JTP events all players must be older than 2 and younger than 20. For a K-12 event, the players must all be students at the school whose scholastic affiliate is sanctioning the event, but that’s done on the honor system. (I know of one instance where the affiliate was asked to provide proof of student status, there may be others.)
That means there must be a birthdate on file for every player. TDs in JTP events are encouraged to collect birthdate information for all players during registration and they are required to collect birthdate and address information for any players without an existing ID. (Gathering email addresses is also encouraged.)
A 10 character field is going to present some challenges with frequent version number changes.
I follow the Discourse development closely, I’ve seen over 200 commits in a single day multiple times.
If whatever native format you use to save the tournament information includes a more precise version number then that can go a long way to helping diagnose problems if something is wrong with the US Chess submission files.
So, if one of the little 1st graders has an up-to-date membership but the birthdate on record is the coach’s or parent’s birthdate, will that get caught early enough to make it possible to get it fixed to allow the tournament to be rated. I would hate to be trying to do the tournament report on the night of the tournament, click the JTP button and have the validation say that Jones, Joseph is 35 years old—we can’t rate this as JTP.
A parent’s birthdate seems less likely because it would have required paying for an adult membership. An older sibling’s is possible (particularly if there was confusion when buying a family membership).
TDs are encouraged to create a set of upload files during the first round and run it through the validator to check for ID and membership issues. Just remember to delete that event from your workarea later on.
As I recall in the past some of the pairing programs required you to put in dummy results before it would create a set of upload files. I don’t know if that’s still necessary.
There are scholastic programs that don’t collect actual birthdates but will put in January 1st as the birthdate, with a year that is usually close to the right one. As a result, we have twice as many members with a January 1st birthdate than for any other day of the year. These same programs often don’t put in member addresses, either, they’ll enter their own address.
Looking at another data source, it appears that in calendar 2023 we had 12,233 events uploaded using the 2C upload format and 788 using the original V1 format.
I’ve been told that VegaChess is still using the V1 format, that might not be the only source of V1 uploads. (As of a few years ago, there was still at least one TD using a DOS version of SwisSys, which goes back to the 90’s.)
Isn’t it time to stop supporting V1? Not having to support these super old formats, while annoying for a few, let’s you serve everyone else much more effectively.
Clearly, there are people still using WinTD 4.10 which dates to 2008 and is the first version that did the 2C. (Anything done with v1 wouldn’t have the software stamp). Interestingly, there are only a handful of “legal” 4.10’s out there because it was almost immediately superseded by 4.11 which was a free update from 4.10. But prior to 4.20, the software had a “honor system” license, and I wouldn’t be surprised if some old software is still floating around on CD’s. There are certainly more than a few TD’s that have their software installed on old laptops that aren’t used for anything other than tournament direction, so the fact that very old software might be incompatible with newer versions of Windows (or MacOS) isn’t an issue.
I don’t know how Leago might handle the programming, but the way I handled it there would be no major support issue handling 2, 5 or more similar DBF upload formats.
Supporting a different type of upload format (such as tab-delimited, JSON or XML) is a different issue.
I recently wrote a small program to take an existing rated event and produce a tab-delimited ‘dump’ file as a way to provide static test cases to Leago for testing their version of the ratings system code, a tab-delimited file would not be difficult to parse and would have advantages over DBF in that the number of fields isn’t fixed, which would make the player/result data easier to format. (We currently limit events to 32 rounds, but that number is arbitrary.)
Having been involved in two rounds of discussion over a new upload format, both of which bogged down over issues like the size of JSON/XML files and arguments over what fields to include, I would personally lean towards the tab-delimited approach using a dictionary of allowable fields at the tournament, section and player level. This could include a ‘RNN’ field for round data.
Decisions about what format(s) to support are made at the policy level.
Adding a new format would require releasing an approved format so that the pairing program authors can choose whether or not to support that format. Dropping a format should involve some advance notice to the software developers as well as affiliates and TDs using older versions.
Events uploaded using the V1 DBF format in calendar 2023 came from 68 different affiliate IDs and 81 different chief TDs.