Hi, Based on the discussion during the online get-together and the tool-chain and release processes used to maintain packages and deploy release media, this is what I’m thinking…
The pipeline used to assemble all the different aspects into a release is very capable. It can handle multiple OS versions without issue. Including things like different names, package sets, specific skews of individual packages and much much more. So... An automated "Testing build" of the OS release media (possibly all versions or just maybe the LiveCD) on a regular schedule. Possible the 1st of every month. This version would be called something like “FreeDOS 2022-06.” It would contain new features and packages, updates and any other changes. This version could easily boot with a message indicating it is a Test Build. At some point, we could decide that there has been enough improvement to warrant a new OS release. When that occurs, we could branch the "Testing Build” into an “RC build”. We would decide at that time if it would be a simple update (like FreeDOS 1.3U1-RC1) or major release (like FreeDOS 1.4, 2.0, etc.). Regardless of which type, the “RC build” would only get bug fixes from that point. During that time, the "Testing Build” could continue to receive general changes. However (excluding bug fixes), the Testing Build would most like sit idle during the testing of the RC Build. When we are satisfied that the RC Build is ready, we just push out the new OS version. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
