Messages in this thread | | | Date | Sun, 26 Apr 1998 12:03:29 +0800 | From | Guan Yang <> | Subject | Re: kernel version scheme |
| |
When will 2.2.x come, then? Also, another [unrelated] question, when there is a patch for instance for 2.0.34, is that patch to upgrade 2.0.33? What will happen when I apply it to an older version?
David Ford wrote: > > On Sat, 25 Apr 1998, Paul Miller wrote: > > hmm... So what is next? 2.2.x? What is the point for changing the patch > > level? Is 2.2.x planning to use new development tools -- egcs for > > example? Or are the 2.1.x features going to be added to 2.2.x? > > And what about 2.1.x, they're up to .98 I think, will 2.1.x change to > > 2.3.x or continue? > > :major.mode.patchlevel: > [for linux] > > major release number: usually signifying a largely different instance of > the software > > mode: usually signifying either release or development > > patchlevel: usually signifying a small set of patches having been > applied at each increment. these patchlevels may or may not make large > changes, this numbering is intended to provide a timeline of change > synchronisation. > > ---- > naturally, the number 100 comes after 99, just as 10 came after 9. > > 2.1.99 -> 2.1.100 -> 2.1.101. please people, let's not run through this > again like we did on 1.3.x :) > > when 2.1.x is deemed an officially ready release kernel, the version will > be incremented to 2.2.0. Linus will make this call in all probability.
No anarchy? ;-)
> > the development tree will then acquire the version number of 2.3.x and > progress will continue. normally release kernels do not have new features > unless the feature is rather important. release kernels tend to have > patches only to fix any little buglets that remained unnoticed. > > x.<even>.x is a release kernel > x.<odd>.x is a development kernel > > as for the use of compilers, several notable people have indicated a > wariness to explicitly support them based on lack of or incorrect > documentation. you are always free to use the other compilers but may > encounter slight difficulty when posting your problems on the list. > several compiler packages are going through development phase and they do > bring certain known/unknown bugs to light. > > your best bet is to thoroughly research the bug you have with different > angles to determine the most probable cause before posting it to a list. > > on a side note, people are encouraged even more so to post concise emails > and list an ftp site instead of including a sizable attachment. it would > also be beneficial to the list for people to review the last week's > postings on the list before posting their problem. often a patch for > their problem has already been posted. > > have a great weekend everyone, and someone get a baby sitter for Linus for > a few hours. he deserves weekends too. =] Well, ... Babysitter!? I thought multitasking _and_ SMP was already implemented. :-)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |