Hi, > On Aug 1, 2022, at 10:51 AM, tom ehlert <t...@drivesnapshot.de> wrote: > > Hallo Herr Jim Hall, > > am Montag, 1. August 2022 um 16:08 schrieben Sie: > >>> Hi! I agree it would be good to have a changelog visible before >>> downloading those 100s of megabytes >> [..] > >>>> I think it's pretty rude behaviour wrt the testers to throw once per >>>> month 500 MB with a bazillion of subprojects at the testers, with only >>>> 'please test this' without any mentioning of >> [..] > > >> I think folks may have missed that there's a changelog in the Interim >> Test Build directory: > >> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/changes.log > >> From my reading of the changelog, almost all of the changes in this >> Interim Test Build from FreeDOS 1.3 are NLS updates, plus some version >> updates of other packages like dojs, jemm, gopherus, and a few others. > > so we should test the version numbers? > > 2022-02-25 06:46:13 gopherus (Shidel): v1.2.1 > 2022-03-02 13:54:44 utf8tocp (Shidel): v0.9.4 > > is not a changelog. a changelog explains the what and why of the > change. not that the change resulted in a new version number. > > version numbers of the packages contained should be possible to obtain > somewhere > else, even if the package didn't change. > > Tom
You are correct that it is not a change log for the programs themselves (like gopherus and utf8tcp). It is however a changeling for the Release itself. Using your example, the Release was updated to v1.2.1 and v0.9.4 for those packages. (I should probably commit with messages like “updated to v1.2.1” instead of just “v1.2.1”. I do need to work on improving my commit messages.) Anyone who would be interested in what changed when updated to v1.2.1 would need to examine the change.log for that specific package. In part, that is because few packages have their development repository in the FreeDOS Archive on GitLab and are maintained elsewhere. In part, it is because the different developers maintain their change.logs in different ways with different formats. In part, it is because highly active projects would pollute the release change log and possibly the log mostly worthless. But perhaps for convenience, it would be better to include those when possible. An example of such pollution is all those “NLS: Package and Description update” entries. After Wilhelm and Berki updated the package descriptions at FD-NLS for DE, FR & TR, I ran an automation tool. It checked each packages LSM metadata and updated it when needed. It also imported any new translations for those packages. Once that was done, if there were any changes, it pushed the updates to the FreeDOS Archive. There were a lot of minor changes spread across nearly all packages. In the future, I may have the RBE filter out such things. The exception to all that is a couple packages that live in the Archive. Like the FDHELPER package. Also projects used directly by the RBE to build the release are included. Like the RBE itself, FD-NLS, FDI and FDI-x86 get all of their messages (with some filtering) included. This is the first interim build and automated change log creation for the release. No doubt there will be changes. (which I’ll need to remember to log) :-) Jerome > > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > <mailto:Freedos-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/freedos-devel > <https://lists.sourceforge.net/lists/listinfo/freedos-devel>
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
