Re: kernel version scheme

Guan Yang (guan@wk.dk)
Sun, 26 Apr 1998 12:03:29 +0800


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