I agree that whatever we put in FreeDOS 1.4 RC2 should be what we include in FreeDOS 1.4. We need to focus our efforts on testing RC2 so we can release 1.4.
Ideally, we would have had all the changes in before releasing RC1. Swapping out bmp2png with dosview is a pretty easy decision. As Jerome said, it's not part of the "core" components of FreeDOS, it's an image utility, no issues in making that change. The current FreeCOM in 1.3 (same as RC1) is 0.85a. This is a good FreeCOM, but it has some bugs that should be fixed, and 0.86 does that. I know I said in an earlier thread (a while ago) that we should hold off on including an updated FreeCOM and kernel in 1.4 so they can be thoroughly tested, with plans to include them in a future FreeDOS "1.5" or "2.0" distribution (which we could release later this year). But having FreeCOM 0.86 in hand, I think it's worth including in RC2. FreeCOM 0.86 has been very solid in my tests, I haven't been able to trigger any bugs in it. Including 0.86 in RC2 will be a further test that I can do everything, including supporting the install process. But I know there's a risk. If we see problems with FreeCOM 0.86 in FreeDOS 1.4 RC2, then we should release an RC3 that reverts back to 0.85a. But if 0.86 works well in RC2, then we could release FreeDOS 1.4 in March (instead of an RC3) using FreeCOM 0.86. **That said, I still think a new kernel (even if it's released soon) should wait for the next distribution. And again, we could release an updated distribution with the new kernel later this year .. and I think a kernel update that supports WfW should bump up the distribution version to FreeDOS "2.0". Jerome Shidel wrote: > > I also did think about wether we or not we should be making this change > during the RC phase. > > Since both BMP2PNG and DOSVIEW are “Utilities”, this > would be changes to the BonusCD. Neither would be installed by > default. Therefore, I don’t think this would qualify as a significant > change and would be okay for RC1. > > However once RC2 is released (next month), I think such things should > be strongly avoided. Changes at that point should be limited to critical > bug fixes only. > > As for FreeCOM, (as you know) there was a lot of very recent work done > on fixing or merging bug fixes. Personally, I saw about half a dozen > of the bugs I reported that are now fixed. That is awesome. However > FreeCOM is a critical part of FreeDOS, it will take time to test. It > would be great if there was a new “official” kernel to test as well. > > But, we are currently sitting on several very important fixes that > we really need to get into the mainstream. Several (like with fdisk), > are your fixes to prevent damaging a partition table just by looking > at a drive. > > Since users will likely just download the latest OS version and not > apply any post-release updates, I think we need to get these out sooner > rather than later. > > As Jim mentioned in an earlier message, the is really nothing that > prevents us from having a “FreeDOS 1.5” release a few months after > the new version of FreeCOM and Kernel have been released and tested. Bernd Böckmann wrote: > > > > But if we start making significant changes to the RCs I strongly suggest > > that we also update FreeCOM to 0.86. Better do one more RC instead of > > shipping with a FreeCOM known to contain some bugs... _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
