Re: [Freedos-devel] Thinking about FreeDOS test releases
Hello Jim, My own thoughts: On Sun, 15 May 2022 at 21:56, Jim Hall wrote: > 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. > Well, for this to work, all the updates on the test releases should be corrective (patches). No new features should be added for this to happen, otherwise, the test releases will fix some bugs and introduce new ones. For this reason, it would be useful that the name contains the point version it is based upon: "FreeDOS Test Build 2023-07 over 1.3" or whatever. However, it is hard that not all tools would have both fix releases and new feature releases. If it were really easy an automated to create new distribution, ideally there could be two lines: one that patches 1.3 and a second one that goes toward 1.4. Aitor ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Thinking about FreeDOS test releases
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
Re: [Freedos-devel] Historical vs. Hysterical Edlin Versions
On Thu, May 12, 2022 at 8:56 PM Gregory Pietsch wrote: > > I'm thinking of editing Edlin to match historical behavior after > downloading a 1982 IBM DOS manual and a 1987 Microsoft OS/2 manual I > found floating around the 'Net. I want to make Edlin still the small > program it has always been without adding things that would make the > executable super-huge, so I want to get some feedback from the list > before I do anything. The things I am considering are below: My thoughts: > 1. At the beginning of the program, when Edlin reads the file whose > name is on the command line, the historical thing to do is output > "End of input file" if the entire input file has been slurped in or > "New file" if the file does not exist yet. FreeDOS Edlin just runs the > same code as the T command to slurp the file in and give the output > of that command, which is the number of lines read. I think "New file" is good when you're starting a new file. But "End of input file" isn't very helpful information. I prefer "X lines read" if it's an existing file. That way, I will know if Edlin read my file correctly. > 2. The IBM DOS manual adds "#" as the line number that's one beyond > the last line. This should be an easy add that doesn't change existing > behavior. That's a nice feature that I'd forgotten about. Yes, that makes sense. > 3. The historical behavior for the Q command is to always verify that > the user wanted to quit the program with an "Abort edit (Y/N)?" message. I think it's always a good idea to verify that the user wants to quit. Yes, this sounds good to me. > 4. Historically, the E command erased any backup copy (i.e. the file > with the .BAK extension) after writing and before quitting. I don't > know if I want to emulate this behavior. I'll sometimes make a backup copy of a file before I edit it, so I might copy FDAUTO.BAT to FDAUTO.BAK before I edit the file, so I can go back to the backup copy later. It would be bad if Edlin deleted my backup copy on its own, just because it had the same "*.BAK" extension. I prefer Edlin not delete files. Jim ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Save the date: FreeDOS virtual get-together on Sunday, May 15
Hi everyone! The get-together starts in a few minutes. You can join here: https://bluejeans.com/984378133/0575 Today's focus is "technical." If Gregory is online, I'd love to hear more about Edlin. We might also talk about the planned ebook. Or about the website usability tests. Or other technical topics. See you soon! Jim On Sat, May 14, 2022 at 8:53 PM Jim Hall wrote: > > Hi everyone > > Here's your reminder of tomorrow's virtual get-together. I'll share the > connection info shortly before the meeting starts. > > See you tomorrow! > > > On Thu, May 5, 2022, 7:22 PM Jim Hall wrote: >> >> I wanted to remind everyone that we'll have the next FreeDOS virtual >> get-together on Sunday, May 15. As always, it's at 11am US/Central. >> Use your favorite timezone converter to find your local time. >> >> We alternate topics every month, and this month's topic is >> "technical." In previous "technical" get-togethers, we've done live >> debugging and talked about other technical issues. We aren't replacing >> the conversation on freedos-devel, but it sometimes helps to have a >> live conversation about something to troubleshoot a problem or bug >> more quickly. >> >> Meeting via BlueJeans worked well last time, so I'm planning to use >> that again. I'll post the meeting URL here earlier that morning (as >> early as I can, schedule permitting). I'll also share the URL on the >> website and on our Twitter account and on the Facebook group. >> >> You can connect to the get-together using any modern browser >> (BlueJeans recommends an updated version of Chrome) or you can >> download the desktop client at https://www.bluejeans.com/downloads >> >> I love the virtual get-togethers, and I'll keep doing them as long as >> folks keep attending. If nothing else, it's a great way to connect as >> more than just emails in your inbox. >> >> >> Jim ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
