Looking ahead to "FreeDOS Next," I wanted to continue the conversation again about test releases for FreeDOS. Before, I called this idea a "rolling release" - but that's not the right term. So that might be why the last conversation on this topic didn't go anywhere.
*Where we are now: We use a point release model for the FreeDOS distribution, where we specifically label each distribution. Skipping the "alpha" and "beta" releases, we've had FreeDOS 1.0, 1.1, 1.2, and 1.3 (and several "Release Candidate" versions in between, such as FreeDOS 1.3 RC1, 1.3 RC2, 1.3 RC3, 1.3 RC4, and 1.3 RC5). DOS doesn't change much, so our releases have been spread out over time. But in that time, developers release new versions of their programs. So between each distribution release, a bunch of individual packages will get updated. But in the current model, most folks have to wait until the next full distribution to see those changes. I'd like to make it easier for everyone to test the latest version of everything. *Short version: We keep the "point release" model, but add a parallel "test" distribution that gets updated once a month. (Could be some other cadence, I'm suggesting monthly because that seems like a good balance to me.) *My thoughts: I'm interested in a parallel test distribution that gets updated on a regular schedule, by an automated (or mostly-automated) process. Let's say there's a new test distribution once a month. Each test distribution contains everything in the distribution that's current when it was built: packages, installer, translations, documentation, etc. For example, imagine monthly test distributions called "FreeDOS Test Build 2022-07," "FreeDOS Test Build 2022-08," FreeDOS Test Build 2022-09," ... you get the idea. These don't have a "1.3" or other version number on them, only a test build label. *How we would use this: We can leave FreeDOS 1.3 distribution as the *stable* release, and continue to make changes in the test distribution. Developers use the monthly test distribution if they want to test interoperability with other recent packages. Folks who want to test can always find the latest version to experiment with. Translators have the latest version. Documenters have the latest version. And so on. The test release label will make it easier to track bugs. "This bug in (program) was reported in FreeDOS 1.3, but that problem in (program) was fixed since then. Download the latest FreeDOS Test Build and see if that fixes it." At some point in the future (let's use July 2023 as an example) we might decide "there haven't been significant changes in the FreeDOS test releases in the last year .. we've only seen package updates, no big distribution changes .. let's make a 'FreeDOS 1.3 Update1' release with the new changes." And then we can promote "FreeDOS Test Build 2023-07" as "FreeDOS 1.3U1 RC1" and go through the testing. Bug fixes go back into the monthly test release, so "FreeDOS Test Build 2023-08" becomes "FreeDOS 1.3U1 RC2," and so on. When testing looks okay, we can release "FreeDOS 1.3U1" with very little effort. Or, maybe we instead decide (let's stick with February 2023 as an example) "there *have* been a bunch of structural changes, but it's looking good." Maybe we've trimmed down the packages, maybe we've changed the installer, or whatever other changes happen in the FreeDOS test distributions. And we get to a point where we decide "this is looking good, I think we can release this as '1.4' or '2.0'." And then we can promote "FreeDOS Test Build 2023-07" as "FreeDOS 1.4 RC1" and start testing. Changes go back into the monthly test release, so "FreeDOS Test Build 2023-08" becomes "FreeDOS 1.4 RC2," and so on until we finally release "FreeDOS 1.4." I think the monthly test release would need to display a big red dialog box when you boot it, saying something like: : This is a test distribution release intended only for testing the : latest changes in FreeDOS, and could be unstable. This is not an : official FreeDOS distribution. If you want the official distribution, : please download FreeDOS 1.3 from www.freedos.org The idea is that anyone who downloads the monthly test release should immediately recognize that this is not the stable distribution. Jim _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
