Hi Jim, >> The current numbering is that "stable plus patches" will be >> 2038 while unstable is 2037 (next unstable will be 2039)... >> Both branches are based on kernel 2035 and for a while they >> even both used 2035 as version number(s), unfortunately.
>> While it does not have a SF file release yet, 2038 combines >> stable 2036 kernel with patches that fix bugs, increase the >> stability or add small, non-experimental features. It could >> be released at any time if necessary, but there are some doc >> updates and small patches what would suit it well :-). > So we've moved to alternating between "stable" and "unstable"? > 2036(stable), 2037(unstable), 2038(stable), 2039(unstable), ... To be honest, since Jeremy disappeared I have little hope that there will be a 2039 unstable. I assume that 2039 will instead be a 2038 with some 2037 backport parts added, 2040 will have some more, and so on, until the rest of unstable can hibernate around in peace, waiting for anybody who wants to either make it stable or wants to add more experimental things to it. Maybe possible improved variants of 2037 could be called 2037b etc. > This is not a good practice. Not even the Linux kernel follows the > "odd numbers are 'devel', and even numbers are stable" version scheme. It did between 2.0 and 2.6 or so afair. And I must say I do not have the impression that the 2.6.x-y numbers are "clear". > A free / open source software project needs to make frequent releases, > with incremental improvements... We should not try to hold a release There were frequent mentions of the snapshots on the Rugxulo homepage here on the list, but I always hesitated to "waste" the version number 2038 by making an official SF file release from one of the clearly in-progress snapshots... Yet maybe an official release is the only way to get testers to wake up...? > (like we seem to be doing with 2038.) Release 2038 now, and put > those other "doc updates and small patches" in a 2039 release. Will try to push the pending patches from my desktop and other sources into the SVN first, then we can use 2039 for bugfixes if we cannot wait to get test results for that SVN snapshot ;-) Still it is a pity that there was so little discussion on the suggested patches by RayeR, Tom, Christian, (others?) on any list. As said, adding tricky patches without review feels bad. Eric ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
