> > 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.
Whatever happens, it is important that new versions of the kernel get released as they happen. Don't wait on 2038 - release it now, and indicate the changes so people can help to test it. If you need to release what you have as 2037b or something, before you feel comfortable releasing 2038, that's fine. But it's important to get the new version out there for people to test. > >> 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". They stopped doing the even-odd numbering, because it was too confusing. http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering Where versions are A.B.C or A.B.C.D >>>>>> The old scheme (after 1.0 and prior to version 2.6): * The A number denotes the kernel version. It is rarely changed, and only when major changes in the code and the concept of the kernel occur. It has been changed twice in the history of the kernel: In 1994 (version 1.0) and in 1996 (version 2.0). * The B number denotes the major revision of the kernel o The kernel used the traditional even-odd system version numbering system. * The C number indicates the minor revision of the kernel. This number was changed when security patches, bug fixes, new features or drivers were implemented in the kernel. After the release of 2.6.0 (Dec 2003) it was realized that a much shorter release cycle would be beneficial. Since then: * A and B are largely irrelevant * C is the version of the kernel * D counts from and bug and security fixes (only) to the C version (all development occurs on release candidates—'rc') <<<<<< >> 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. You aren't "wasting" a version number. It's just a label. > 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. The review will happen when the version is released. It's possible that the people you mentioned saw nothing needing comment, so did not respond. -jh ------------------------------------------------------------------------------ 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
