I think there is so much confusion about the Entered-date fiels, that maybe we should switch on using version 4.
"The 1999-12-22 version (version 4) is only a minor change from version 3.
- First, version 4 entries begin with a line containing "Begin4" rather
than "Begin3".
- The other difference is that dates are now in the format specified in
Because in version 4, the Entered date is defined as:
The 1999-12-22 version (version 4) is only a minor change from version 3.
- First, version 4 entries begin with a line containing "Begin4" rather
than "Begin3".
- The other difference is that dates are now in the format specified in
But we use version 3, where it should be:
Entered-date: Date in format ddMMMyy of when the LSM entry was last
modified, where dd is 2-digit day of month, MMM is
ALL-CAPITALIZED first 3 English month letters, and yy
is last two digits of the year in the Gregorian
calendar. Note that you should fill in both Version
and Entered-date.
Also, I come on the subject because for Bolitare, we now have:
Begin3
Title: Bolitaire
Version: 0.62b
Entered-date: 2015-12-04
Description: A Freecell card game
Author: Yogesh
Copying-policy: GNU General Public License, Version 2
Summary: A Freecell card game for DOS.
Modified-date: 2025-03-23.2
End
Where a Modified-date was added, but Entered is supposed to be the date of last modification (both in
version 3 and 4)
When going through all of the various packages available to FreeDOS, the Entered-Date field was a complete and total mess.
Sometimes the value was the “very first time the package was created”,
Sometimes “when that version was created”,
Sometimes “when anything in the package was updated”,
Sometimes “only when the binaries were updated"
Sometimes the build time which was neglected for a few versions,
and other values which possible meant something to someone.
On top of that, the information was represented in whatever format the individual felt like using. For example:
23mar15, 23MAR15, 23-MAR-15, 23-March-2015, 3/23/15, 03/23/2015, 15-03-23, and on and on.
This haphazard gathering of various formats is a pain to process through simple automation and makes operations like sorting difficult.
But more important, when viewing lists of packages on the download /update repositories it looked atrocious and unprofessional.
Most of this likely occurred from the lack of any automation. It would require whoever included the update to always examine the
field for accuracy and format consistency every single time a package changed.
So a long while back, I went through and standardized that field in all packages on the YYYY-MM-DD format. I also have the Repository
Management Utility (aka FDREPO) verify the correct format is used. If it is not, it will reject the package and not add it to the download/update
repo until it has been corrected. But, that information is still rather inconsistent and useless.
Hence, the Modified-date field was added and its format is enforced by the utilities. Eventually when the field is present (always on the download
Repository), tools like FDIMPLES will use that field instead of relying on parsing the Version or trying to use Entered-date.
When editing an LSM, the Modified-date field is not something to be concerned about adjusting. Originally, it was only added the the LSM
by the FDREPO when it was not present and the package was added to a download repo (usually my unofficial repository). I would then
download the updated version and upload that to the official repository. This would keep the packages identical.
The recent update to FDVCS includes support to update that field using a slightly different method. It will scan the entire package finding
the latest updated file. It will then use that timestamp to update that field and apply the same timestamp to the LSM file. Assuming
the file timestamps are correct, this make sure the modified-date field is accurate to the last change of the package contents.
Since whenever a package at GitLab is updated, I will update my local copy, apply the timestamp preservation routine in FDVCS and
some other housekeepings stuff. Then, I will push the updated information back to GitLab. GitLab does not preserve timestamps on its
own. So depending on wether or not the individual who initially pushed the changes used FDVCS to update the timestamp, the record
times can be off a few days.
As a bonus, I can update the Modified-date field in every package in just a few minutes using the new FDVCS tool. Under a local directory
which contains all of the projects, I can simply run:
fdvcs.sh -ens -fe -f -mod -c “udpdate metadata modified-date field”
Breaking that command down…
-ens (Error No Stop) Do not stop processing additional projects with a “ForEach” if an errors occurs. Just move on to the next project.
-fe For each project, perform the following built-in commands of the utility
-f (Fetch) If there are any updates to the project on the server, pull them.
If needed, update the timestamp database and restore the timestamp of files.
-mod Find the latest updated file. If needed, Update or Add the modified-date field and LSM timestamp.
-c If needed, Create a new INDEX.md page with updated metadata.
If needed, update the timestamp database file.
If needed, commit and push the changes back to GitLab.
At some point in the near future, I am likely to have the Commit/Push option automatically perform -mod and -lfn.
While the information in the Entered-date is anyones guess to what it represents, the Modified-date field is kept reasonably
accurate through various automated utilities. I am currently working on the next version of FDREPO and it will contain the
same logic for setting that field if for some reason it is not present. Same goes for the next edition of the RBE. Probably
for the current RBE version after 1.4 is released when it is switched over to the new version of FDVCS.
Among several other things, I recently used FDVCS to update/add that field and perform some other cleanup across
all of the projects. That includes the removal of all current CI/CD runners. When the new version of FDREPO is done,
I will likely create a new CI/CD for the projects. One that only performs verification of the project directory structure and
metadata files. Since packages can be created locally with FDVCS or downloaded from the IBIBLIO Repository, it will no
longer create “packages” on GitLab itself.
:-)
Jerome
_______________________________________________Freedos-devel mailing listFreedos-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-devel