Hi Tom > On Nov 1, 2024, at 1:09 PM, tom ehlert via Freedos-user > <freedos-user@lists.sourceforge.net> wrote: > > Hallo Herr Jerome Shidel > >> Also, FreeCOM and Kernel are using Unstable branches on the Interim Build. > >> There have not been any commits to the unstable Kernel branch. So, it is the >> same as the master branch which is the version provided with FreeDOS 1.3. > > so, the unstable kernel 1.3 is exactly the same as some previous 1.3.
Yes, But… Yes. On the FreeDOS GitLab Archive, I set up a unstable branch for testing newer kernels a while back. However, I have not been provided with a newer kernel to put in there for testing. The unstable branch contains kernel 2043. The same version that shipped with FreeDOS 1.3. But, The development of the kernel takes place over at https://github.com/FDOS/kernel There have been updates to the kernel since the 2043 release. However, no more recent versions have been released. There have been about a dozen fixes. Most very important. The one that concerns me personally is https://github.com/FDOS/kernel/issues/148 which was causing FDIMPLES (and some other programs) to crash in weird ways. Had to do with the MCB chain if I recall correctly. >> On the other hand, the unstable branch of FreeCOM contains a test version of >> the command shell which is using the same version number as the previous >> shell. > > so we have some unchanged and some changed version of freecom, both by the > same number. Yes, sort-of… Like the kernel, the most recent official release of FreeCOM was 0.85a released back in 2021. There has not been a more recent official release. However, for testing purposes, I was able to coerce a copy of a build that included many of the more recent patches and bug fixes. Since, this was not an “official” release, it was not assigned a new version number. >> It contains fixes for many bugs that were in the prior version. > what bugs specifically? *many* is a bit -ah- generic. See everything (around 12 fixes) after July 10th, 2021 at https://github.com/FDOS/freecom/issues?q=is%3Aissue+is%3Aclosed Or, simple see https://github.com/FDOS/freecom/issues for the roughly 19 things that are still broken. > there used to be good old times, when there would be 2 pointers to old > ('unstable') and new ('test') versions, + a list of bugs hopefully fixed, > both available without downloading and > installing 500+MB of 'distribution', which could be downloaded, expanded to a > directory of my desire, and tested. > > Seriously, guys, if you think that is the new way to develop quality > software/OS,please follow Gregory ('Just go away, then 5000 Miles straight > ahead.') I do not dis-agree. The FreeDOS GitLab Archive, Release Build Environment, Online Repositories and everything in the pipeline to generate packages and releases has been made to support the ability to just fetch a test build. The Gitlab Archive is the staging are for different packages. Some have unstable branches. Any branch can be downloaded for testing. The RBE will generate either a Interim Test Build that uses unstable branches when they exist. Or, a Release that only pulls from master branches. The Online Repositories have packages that can be downloaded and installed either with a browser or command line utilities in FreeDOS. These repositories can host both Release and Unstable versions of packages. It has done so in the past and can again. When we were working on FreeDOS 1.3 there were “unstable” and “release” versions of the kernel and FreeCOM in the Online Repository. The monthly Interim build is a great way to test that the OS build is functioning properly. But, you are very correct. If all you want is to test PROGRAM_A or DRIVE_B, it is a waste to download the entire build. The Online Repositories make doing that relatively easy. But, we need builds in order to make them available for testing. > >> I would really like to see a new official release which contains these fixes >> and others for T2412. > >> Side note… One really nice thing about having a batch file based OS >> installer, it relies heavily on the shell. The installer hammers >> relentlessly on numerous features the shell provides. > > Side note: your installer tests only a very limited subset of required > COMMAND features. Testing these features multiple > times over and over doesn't make the 'test' more exhaustive. True. But, it does use many of the features that can be used by a batch file provided by the shell. If any of the ones used have a problem, you will most likely notice it very quickly. When initially creating the installer, I discovered several unknown bugs. That had a couple side effects. For some, it just meant handling a process a different way. But for others, it required entire sections of code that should not be needed. It was a long time ago. So, don’t bother asking "what bugs”. I really only remember the most annoying one. That was the one that caused me the biggest headaches and extra code in the installer. Basically, sometimes FreeCOM would loose data being piped between programs. This would occur sporadically. Usually, it would happen sometimes immediately after starting to execute a sub-batch. To solve the problem, the installer performs a validation check on the result of a pipe to ensure the data was successfully set. If not, it repeats the process. The result would be set correctly by the second or third attempt. But, it “should not" be needed and adds a lot of hard to read cruft in the installer. > Tom :-) Jerome _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
