2.8.0?
| From: | Linus Torvalds <torvalds-AT-linux-foundation.org> | |
| To: | Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>, linux-arch-AT-vger.kernel.org, DRI <dri-devel-AT-lists.freedesktop.org>, linux-fsdevel <linux-fsdevel-AT-vger.kernel.org>, linux-mm <linux-mm-AT-kvack.org> | |
| Subject: | (Short?) merge window reminder | |
| Date: | Mon, 23 May 2011 12:13:29 -0700 | |
| Message-ID: | <[email protected]> | |
| Cc: | Greg KH <gregkh-AT-suse.de>, Andrew Morton <akpm-AT-linux-foundation.org> | |
| Archive‑link: | Article |
So I've been busily merging stuff, and just wanted to send out a quick
reminder that I warned people in the 39 announcement that this might
be a slightly shorter merge window than usual, so that I can avoid
having to make the -rc1 release from Japan using my slow laptop (doing
"allyesconfig" builds on that thing really isn't in the cards, and I
like to do those to verify things - even if we've already had a few
cases where arch include differences made it less than effective in
finding problems).
And judging by the merge window so far, that early close (probably
Sunday - I'll be on airplanes next Monday) looks rather likely. I
already seem to have a fairly sizable portion of linux-next in my
tree, and there haven't been any huge upsets.
So anybody who was planning a last-minute "please pull" - this is a
heads-up. Don't do it, you might miss the window entirely.
Did I miss any major development mailing lists with stuff pending?
Linus
PS. The voices in my head also tell me that the numbers are getting
too big. I may just call the thing 2.8.0. And I almost guarantee that
this PS is going to result in more discussion than the rest, but when
the voices tell me to do things, I listen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Posted May 23, 2011 20:05 UTC (Mon)
by Oddscurity (guest, #46851)
[Link] (7 responses)
Posted May 23, 2011 20:08 UTC (Mon)
by bmillemathias (guest, #54343)
[Link] (4 responses)
Posted May 23, 2011 20:20 UTC (Mon)
by danielpf (guest, #4723)
[Link] (3 responses)
Posted May 23, 2011 20:29 UTC (Mon)
by viro (subscriber, #7872)
[Link] (1 responses)
Posted May 23, 2011 21:27 UTC (Mon)
by jengelh (guest, #33263)
[Link]
Posted May 23, 2011 20:38 UTC (Mon)
by creemj (subscriber, #56061)
[Link]
That spot is already taken.
How about Omega --- the algorithmic halting probability? :-) :-) :-)
Posted May 23, 2011 20:17 UTC (Mon)
by jcm (subscriber, #18262)
[Link]
Posted May 23, 2011 21:03 UTC (Mon)
by a9db0 (subscriber, #2181)
[Link]
C'mon Linus, give us a kernel dedicated to Douglas Adams.
Posted May 23, 2011 20:17 UTC (Mon)
by yokem_55 (subscriber, #10498)
[Link] (3 responses)
Posted May 23, 2011 20:24 UTC (Mon)
by linuxrocksrulers (guest, #75128)
[Link]
Posted May 24, 2011 0:54 UTC (Tue)
by vblum (guest, #1151)
[Link] (1 responses)
Posted May 24, 2011 13:42 UTC (Tue)
by linuxrocksrulers (guest, #75128)
[Link]
USUAL KERNEL
MODERN KERNEL
Hah
Posted May 23, 2011 20:25 UTC (Mon)
by yoshi314 (guest, #36190)
[Link] (3 responses)
Posted May 23, 2011 20:49 UTC (Mon)
by kragil (guest, #34373)
[Link] (1 responses)
What I would like to see is a "stable" versioning algorithm.
Posted May 23, 2011 22:28 UTC (Mon)
by kragil (guest, #34373)
[Link]
(int)(Linux age / 10) + 1
Posted May 25, 2011 15:07 UTC (Wed)
by jonescb (guest, #74600)
[Link]
Posted May 23, 2011 20:36 UTC (Mon)
by prometheanfire (subscriber, #65683)
[Link] (3 responses)
Posted May 24, 2011 3:43 UTC (Tue)
by idupree (guest, #71169)
[Link] (2 responses)
(I seriously noticed this sometime.)
Posted May 24, 2011 20:53 UTC (Tue)
by xtifr (guest, #143)
[Link] (1 responses)
(And what's with the anti-Wordpress dig? It's not something I use, particularly, but it's free/libre/open source, and probably of interest to more people than the gory details of the kernel.)
Posted May 25, 2011 2:39 UTC (Wed)
by idupree (guest, #71169)
[Link]
(Wordpress is just some random piece of software that I use. I guess it has the searchability problem that adding "wordpress" to your Google phrase finds you people's blogs, not just info about the software. And on their blog, maybe they were talking about a version of SimCity or something...)
Posted May 23, 2011 21:38 UTC (Mon)
by smadu2 (guest, #54943)
[Link] (1 responses)
Although its sad it was version bloat rather than something major happening (like rapture) that warranted this change.
Posted May 23, 2011 21:59 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted May 23, 2011 22:02 UTC (Mon)
by copsewood (subscriber, #199)
[Link] (9 responses)
Posted May 23, 2011 22:16 UTC (Mon)
by kragil (guest, #34373)
[Link]
Posted May 23, 2011 22:20 UTC (Mon)
by alspnost (guest, #2763)
[Link] (4 responses)
Posted May 24, 2011 8:09 UTC (Tue)
by gilboa (guest, #23856)
[Link]
Posted May 24, 2011 21:01 UTC (Tue)
by xtifr (guest, #143)
[Link] (2 responses)
Of course, if he jumps to 2.8, then he's got the option of restarting the development branches, starting with 2.9, whereas if he makes 2.7 a release branch, it pretty much commits the project to not using odd-numbered development branches for a long time. So if he wants to keep that option open, jumping to 2.8 makes sense, but otherwise, it seems pointless and a bit weird.
Posted May 25, 2011 11:01 UTC (Wed)
by sorpigal (guest, #36106)
[Link] (1 responses)
Posted May 25, 2011 11:42 UTC (Wed)
by foom (subscriber, #14868)
[Link]
Posted May 24, 2011 6:47 UTC (Tue)
by khim (subscriber, #9252)
[Link] (2 responses)
Yes and no. IPv5 was fringe experimental protocol (and it was not actually called IPv5 but it's authors), but it still took the slot. There are nothing to do this for Linux: AFAICS 2.7 was never used by anyone.
Posted May 24, 2011 21:07 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
It was invoked by our friendly legal clowns the SCOG people, who complained that it was one of the versions of linux that infringed their precious eye pee.
Cheers,
Posted May 25, 2011 6:00 UTC (Wed)
by khim (subscriber, #9252)
[Link]
I think only pointer to the version 2.7 exist. They just used time machine to fine complaint and missed correct time frame. That's why they lost: Linux currently does not infringe but it will. To not escalate time paradox any further we must create version 2.7 ASAP.
Posted May 23, 2011 22:19 UTC (Mon)
by cesarb (subscriber, #6266)
[Link] (37 responses)
Posted May 24, 2011 0:00 UTC (Tue)
by agrover (guest, #55381)
[Link] (36 responses)
Posted May 24, 2011 2:16 UTC (Tue)
by xxiao (guest, #9631)
[Link] (35 responses)
Year.Month can be used for good, no need to worry about 2.8, 3.0, 3.2, which is boring.
"What, why are you still using Linux 2004.06, that's too old, upgrade now!"
Posted May 24, 2011 3:43 UTC (Tue)
by pflugstad (subscriber, #224)
[Link] (31 responses)
Posted May 24, 2011 4:18 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (22 responses)
We don't know precisely when the next version of Linux will be released, so we don't know what it's name will be, so we cannot give meaningful names to the -rc releases that precede it.
I guess we could just decide that the next release will be 11.07 and if slips through to an August release date, we don't worry about it.
Posted May 24, 2011 4:32 UTC (Tue)
by xxiao (guest, #9631)
[Link] (12 responses)
maybe it's time for Linus to stick to the 6-month release cycle now? this may bring efficiency for related projects as well, also you can have the long-term kernel every few years, this is how ubuntu works these days and it's quite good in practice I think.
Posted May 24, 2011 6:16 UTC (Tue)
by corsac (subscriber, #49696)
[Link] (11 responses)
It's more like ~70 days, which is just above two months. Where do you pick that half a year from?
> maybe it's time for Linus to stick to the 6-month release cycle now? this may bring efficiency for related projects as well, also you can have the long-term kernel every few years, this is how ubuntu works these days and it's quite good in practice I think.
Well, ubuntu is fairly new in this game, but Gentoo was already using that release scheme (when they were still releasing). And that releasing scheme is not really a good indicator in case of a kernel. 2.6.32 has been released dec 3rd 2009 so it would have been called 2009.12 (or even 2009.9 if we count the merge window close) but latest release of that kernel was yesterday so it's not really a good indication of the level of support.
You can't say you have a two-years old kernel, you *must* upgrade, it's just wrong. All in all, I don't even think it's worth discussing that scheme, sorry for losing your time...
Posted May 24, 2011 6:29 UTC (Tue)
by dlang (guest, #313)
[Link] (10 responses)
yes, 2.6.39 contains some bugs that aren't in 2.6.32.x as well, and each organization should balance the risk of new bugs vs the risk of bugfixes not getting backported.
Posted May 24, 2011 6:31 UTC (Tue)
by dlang (guest, #313)
[Link] (5 responses)
Posted May 24, 2011 6:34 UTC (Tue)
by corsac (subscriber, #49696)
[Link] (4 responses)
Sure, that's a lot easier than 3.0.42
Posted May 24, 2011 7:30 UTC (Tue)
by dlang (guest, #313)
[Link] (3 responses)
3.0.42
or
2009.9.2.9/2009.9.33
either way you do the date thing, you can then see how old the base kernel is, and figure out how recently it was updated (which also lets you notice when an old kernel series is no longer being updated)
Posted May 24, 2011 7:43 UTC (Tue)
by corsac (subscriber, #49696)
[Link] (2 responses)
My point is that we (usually) don't care how old the base kernel is for stable series.
Posted May 24, 2011 8:30 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
there are a _lot_ of things that don't get backported, some is hardware support, some is performance improvements, some are cleanups of code that may or may not fix bugs, some are bugfixes that people don't think are important enough, some are bugfixes that are considered too intrusive/dangerous to backport.
the number of people working on doing backports is rather small compared to the number of people working on the latest versions
look at the number of patches in a -stable release, even the big ones are seldom more than 100-200 changesets, out of the 10,000 or so changesets in each new release. even if there are a LOT of -stable releases for a particular kernel, the number of changes that get backported are considerably less than 10% of the changes that go into the next release, and as a kernel gets older, fewer changes are backported. by the time you get to a kernel that's 10 releases back, I would guess that far fewer than 1% of the changes have been backported
actually, we can look at numbers for this (fun with git)
2.6.27 - 2.6.37 had 113521 changesets
2.6.32 - 2.6.39 had 76108 changesets
2.6.38 - 2.6.29 had 11031 changesets
so I was a little off in my 1% guess, and I don't have the most recent versions of all the longterm kernels (I pulled from kernel.org and from the stable tree)
but do you really want to bet that the rest of the changes that did't get backported are really all for things you don't need?
Posted May 24, 2011 8:36 UTC (Tue)
by corsac (subscriber, #49696)
[Link]
This is more an advantage than a drawback.
> the number of people working on doing backports is rather small compared to the number of people working on the latest versions
Sure, but the changes are different too. And that's also why a lot of distributions use 2.6.32 for their stable, long time support release. So the stable maintenance work is shared.
> even if there are a LOT of -stable releases for a particular kernel, the number of changes that get backported are considerably less than 10% of the changes that go into the next release, and as a kernel gets older, fewer changes are backported. by the time you get to a kernel that's 10 releases back, I would guess that far fewer than 1% of the changes have been backported
That's the whole point of having stable releases.
> but do you really want to bet that the rest of the changes that did't get backported are really all for things you don't need?
Yes
Posted May 24, 2011 6:33 UTC (Tue)
by corsac (subscriber, #49696)
[Link] (3 responses)
If you read again, you'll see I didn't say that.
> yes, 2.6.39 contains some bugs that aren't in 2.6.32.x as well, and each organization should balance the risk of new bugs vs the risk of bugfixes not getting backported.
2.6.39 (and all release since 2.6.33) are just that: new releases, with tons of new stuff added, stuff removed, lot of changes etc. 2.6.32 is *stable* release, which is something people really needed, especially at the kernel level. And it does get a lot of fixes, either directly or backported when needed.
On top of that, distributions do a good job filling the gap of the new hardware support by carefully backporting some drivers changes when needed.
Posted May 24, 2011 7:23 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
Posted May 24, 2011 7:42 UTC (Tue)
by corsac (subscriber, #49696)
[Link] (1 responses)
I think you underestimate that amount, the amount of people working on that, the amount of time spent on that and the importance it has.
Posted May 24, 2011 11:15 UTC (Tue)
by nicooo (guest, #69134)
[Link]
the amount of time wasted on that
ftfy
Posted May 24, 2011 5:08 UTC (Tue)
by dlang (guest, #313)
[Link] (5 responses)
Posted May 24, 2011 5:37 UTC (Tue)
by kragil (guest, #34373)
[Link] (4 responses)
Just imagine:
Posted May 24, 2011 5:57 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (2 responses)
I would have thought so to, but at the kernel summit when Linus ran his "straw poll" (https://lwn.net/Articles/413061/) he didn't even ask for votes for that option as he assumed almost no-one would want it (and based on the votes he got for the other options, there is a fair chance he was right).
Posted May 24, 2011 6:19 UTC (Tue)
by kragil (guest, #34373)
[Link] (1 responses)
Posted May 24, 2011 6:35 UTC (Tue)
by neilbrown (subscriber, #359)
[Link]
The way I remember it, there where 3 options:
Vote went:
Posted May 24, 2011 6:16 UTC (Tue)
by dlang (guest, #313)
[Link]
wouldn't that be nice?
Posted May 24, 2011 9:27 UTC (Tue)
by epeeist (guest, #1743)
[Link]
Posted May 26, 2011 17:27 UTC (Thu)
by PaulDickson (guest, #478)
[Link] (1 responses)
This would mean that we could have 2012.6 (or 12.6) released in 2013.
Posted May 30, 2011 20:28 UTC (Mon)
by Max.Hyre (subscriber, #1054)
[Link]
Posted May 24, 2011 6:59 UTC (Tue)
by job (guest, #670)
[Link] (2 responses)
It's mostly an excuse to have large version numbers, I think. What would be useful is information if a certain API is included, but that would not be very practical (imagine 2.6.nobkl.fuse.iwlwifi.etc...).
Posted May 24, 2011 7:22 UTC (Tue)
by kragil (guest, #34373)
[Link] (1 responses)
Kernel devs may not need the dates, but it would help consumers comparing products that ship with Linux inside. Most grandmas won't care, but geeks and "prosumers" will.
My hope is that a date based scheme would put a little more pressure on companies to work upstream and ship recent kernels.
But as I already said: Red Hat, HP, Google etc won't like it and they at the end of the day pay the bills for most of people deciding this, so it won't happen.
Posted May 24, 2011 10:38 UTC (Tue)
by joib (subscriber, #8541)
[Link]
Well, if Linus goes ahead with 3.0 then it's a date based system, as Linus says himself. Namely 3.x is the x'th release in the 3rd decade since Linux was born. Perhaps Linus just doesn't want to base his versioning on the birth date of some religious figure.. :-/
Also, perhaps Linus shouldn't base his versioning on such provincial time units as various stuff related to how fast the earth rotates around its own axis and the suns. I vote for megaseconds (Ms) since the epoch!
As to the question whether some group will find the kernel version numbering scheme easy to understand, or acceptable, or whatever: Those for whom the kernel version matters can certainly figure out whatever scheme is used (as long as higher number == newer), for the rest it doesn't really matter (does your PHB know the version number of the Windows kernel in his laptop? No, I didn't think so either)
Posted May 25, 2011 0:40 UTC (Wed)
by pflugstad (subscriber, #224)
[Link] (3 responses)
Yes I know all the other arguments about why you would want to use 2.6.27, but think about this: when 2.6.27 came out, a number of devices we use use frequently weren't even on the drawing board, or were brand spanking new and still being debugged (SSDs anyone?).
Posted May 25, 2011 17:37 UTC (Wed)
by jzbiciak (guest, #5246)
[Link]
Posted May 27, 2011 2:46 UTC (Fri)
by jd (guest, #26381)
[Link] (1 responses)
Now, one could argue that using events gives no indication of the time involved. However, when we talk of a kernel being "old" we don't been chronologically. What we mean is that the accumulation of time has resulted in a large enough change that the original is no longer tolerable.
It would, perhaps, be useful to increment by the number of significant kernel changes rather than by 1, at the cost of bloating the version number a bit. Gives more info, but only if there's a consensus on what is significant.
Chronological versioning, when the interval for a kernel is indeterminate (critical patches may come late and require several rounds of testing, for example, even for kernels with no user-significant changes), doesn't seem to tell you anything.
Posted May 27, 2011 3:20 UTC (Fri)
by neilbrown (subscriber, #359)
[Link]
On what evidence do you base that claim?
It hasn't always been this way but the current release process is very much time based. There is a 2 week merge window for bugs to be added (as well as new features), then a 2 month (approx) stabilisation period for most of those bugs to be removed (but no new features). Then Linus releases and we repeat.
Linus does have some discretion to adjust those times and to extend or shorten the stabilisation period as seems appropriate, so there is a small extent to which events do drive the release, but it is mostly time based.
Posted May 25, 2011 10:35 UTC (Wed)
by danielos (guest, #6053)
[Link]
Posted May 24, 2011 7:47 UTC (Tue)
by cate (subscriber, #1359)
[Link]
Now it is pretty simple, with a blind 'wget'. And anyway the kernel version are also binary 8-bit coded, so numbers should be <255. I don't know if this could be patched (stable API).
Posted May 25, 2011 15:18 UTC (Wed)
by jonescb (guest, #74600)
[Link] (1 responses)
Posted May 25, 2011 19:56 UTC (Wed)
by dlang (guest, #313)
[Link]
making the version be year-2000 will take us to 2255, which is long enough for that field to be expanded to more than 8 bits.
besides, don't you know that everything will be re-done by 2038 anyway when time_t runs out? that's the date to worry about, not 62 years later.
Posted May 24, 2011 5:53 UTC (Tue)
by ldo (guest, #40946)
[Link] (3 responses)
So when do we move to stardates?
Myself, I started numbering one or two projects based on the number of days (including fractions) since 00:00:00 01-Jan-1970 UTC. Generally one decimal place is enough. For example:
Julian is here.
Posted May 24, 2011 6:23 UTC (Tue)
by ncm (guest, #165)
[Link]
Posted May 24, 2011 12:47 UTC (Tue)
by stijn (subscriber, #570)
[Link] (1 responses)
Posted May 24, 2011 22:48 UTC (Tue)
by Karellen (subscriber, #67644)
[Link]
Posted May 24, 2011 7:38 UTC (Tue)
by rilder (guest, #59804)
[Link] (1 responses)
Posted May 24, 2011 9:56 UTC (Tue)
by exadon (guest, #5324)
[Link]
Posted May 24, 2011 10:04 UTC (Tue)
by przemoc (guest, #67594)
[Link] (4 responses)
{2.8,3.0}.x, year.month, etc.
I have other proposal, that does not address particularly Linus' concern, yet still has some upsides.
2.(year - 2000).(continuity of current patch version)
I wouldn't introduce it before 2012, to avoid for the last time use of odd number and to prepare users for upcoming change.
2.12.42
and later 2.12.43, 2.12.44, 2.12.45, 2.13.46, and so on...
It's good because of:
And in year following .99 hit (in ~14 years), patch version would be zeroed to avoid use of 3 digits (obviously for releases after .99 in the same year it is unavoidable). I really doubt that in future anyone will be using 14 year old kernel, so such resetting isn't harmful at all.
YMMV
Posted May 24, 2011 13:13 UTC (Tue)
by edlenz (guest, #12021)
[Link] (1 responses)
Posted May 25, 2011 17:40 UTC (Wed)
by jzbiciak (guest, #5246)
[Link]
Posted May 24, 2011 13:35 UTC (Tue)
by kragil (guest, #34373)
[Link] (1 responses)
Read the PS. again.
Posted May 25, 2011 19:01 UTC (Wed)
by przemoc (guest, #67594)
[Link]
Maybe read again my comment, where I clearly wrote that "[my version numbering proposal] does not address particularly Linus' concern".
Posted May 24, 2011 11:00 UTC (Tue)
by exadon (guest, #5324)
[Link] (2 responses)
Posted May 24, 2011 11:29 UTC (Tue)
by marduk (subscriber, #3831)
[Link]
Posted May 24, 2011 13:38 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link]
Posted May 24, 2011 12:03 UTC (Tue)
by dakt (guest, #74570)
[Link]
Posted May 24, 2011 13:49 UTC (Tue)
by MisterIO (guest, #36192)
[Link]
Posted May 24, 2011 15:22 UTC (Tue)
by mlankhorst (subscriber, #52260)
[Link]
diff --git a/Makefile b/Makefile
--
Posted May 25, 2011 9:58 UTC (Wed)
by Janne (guest, #40891)
[Link] (1 responses)
Posted May 25, 2011 14:50 UTC (Wed)
by proski (subscriber, #104)
[Link]
Posted May 26, 2011 10:07 UTC (Thu)
by domo (guest, #14031)
[Link]
3.12 - 3.99
reasoning:
1) 2 digits less than 3 (3rd digit for maintenance releases)
Note that if there is like 6 releases per year, this numbering scheme
Posted May 26, 2011 21:17 UTC (Thu)
by ortalo (guest, #4654)
[Link]
Noooooooo!
Noooooooo!
Noooooooo!
Linus might choose 2.7.1828... the place is not yet taken.
Noooooooo!
Let's pick 1.61 ... oh damn, we're past that. Then, 2ε it should be.
Noooooooo!
Noooooooo!
Metafont 2.718281 (TeX Live 2009)
Noooooooo!
Noooooooo!
2.8.0?
2.8.0?
(Ubuntu website is "marketing" too much...)
2.8.0?
2.8.0?
2.6: 2006
2.8: 2008
2.10: 2010
2.12: 2012
2.8.0?
2.8.0?
And anyways most stuff is FOSS and can be changed. If no breakage would be a valid argument we would end up with 2.6.2323.47 which is just pathetic.
3.0?
2.8.0?
2.8.0?
2.8.0?
2.8.0?
2.8.0?
2.8.0?
2.8.0?
No 2.7 ?
No 2.7 ?
Hmmm, it's almost like you're new to this game! It's been so long since 2.5 that people have forgotten there used to be development series numbered 2.[odd] :)
No 2.7 ?
No 2.7 ?
No 2.7 ?
No 2.7 ?
No 2.7 ?
Actually there was...
But I suppose something similar happened between IPv4 and IPv6, there never was a genuine v5.
Actually there was...
Wol
Have they shown this version to the world?
Emacs solution
Emacs solution
Emacs solution
sounds better than
"Gosh, what is 2.6.7? when was it released?"
Date based
Date based
Or we could aim for early July, but call it 11.08.. then it is will probably be released early and we will look like we are very efficient.
Date based
Date based
Date based
Date based
Date based
Date based
3.9.3
3.10.0
2011.2.0.4/2011.2.4
2011.5.0
Date based
Date based
2.6.27 - 2.6.27.57 had 2891 changesets
2.6.32 - 2.6.32.27 had 2892 changesets
2.6.38 - 2.6.38.7 had 3101 changesets
Date based
Date based
Date based
Date based
Date based
Date based
Date based
That brand new HP phone ships with Linux 2009.12?
Super awesome Enerprise Linux 15.6 Could Edition uses a patched 2005.1 kernel?
Date based
Date based
Date based
A - no change
B - next version 3.0
C - change to date format.
A - 42
B - 33
C - let's not bother, no-one wants that.
Date based
"We don't know precisely when the next version of Linux will be released, so we don't know what it's name will be, so we cannot give meaningful names to the -rc releases that precede it."
So why not base the name on the month that it was started rather than the month that it was finished?
Date based
Date based
Date based
(or 12.6)
But what about the Y3k problem?
Date based
Date based
And lazy companies couldn't BS people with stuff like: "We support the 2.6 kernel"
Well, first of all kernel releases are time based. So normal version numbers make less sense than date based ones. That just valid and logical.
Date based
Date based
Date based
Event based
Event based
Date based
However there are so many technological change and improvements between version that i could not increase the more significative digit, and the least is too less...
In my opinion if Linus thinks that progressive change has lead to a technological gap that make, say, 2.6.12 a totally different thing than 2.6.40, and most developer (and user, say C developer) feel the same, it is ok to switch to 2.8.0
.. Maybe there is a bit of marketing, but it make sense
Let's update the kernel! Hmm. what patches I should download?
Emacs solution
Emacs solution
Emacs solution
Gimme Stardates!
ldo@theon:~> bc <<<"scale = 1; ($(Julian -f) - 2440588) / 1"
15118.2Gimme Stardates!
Gimme Stardates!
Gimme Stardates!
2.8.0?
2.8.0?
2.(year-2000).x
Presumably first release in the new year would be:
- 2.x preservation,
- hinting the year of non-stable-point release,
- continuity in patch (AKA Makefile's sublevel) version numbering, which is presumably the most important part here - so you can use it alone [e.g. .42] w/o ambiguities.
2.(year-2000).x
2.(year-2000).x
2.(year-2000).x
2.(year-2000).x
Why bother?
Why bother?
Anything this breaks deserves to be broken, and was going to break sooner or later anyway simply because the fields of Linux version numbers are only 8 bits wide.
Why bother?
2.8.0?
2.8.0?
2.8.0?
index 123d858..98132f4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
-VERSION = 2
-PATCHLEVEL = 6
-SUBLEVEL = 39
+VERSION = 2012
+PATCHLEVEL =0
+SUBLEVEL = 0
EXTRAVERSION =
-NAME = Flesh-Eating Bats with Fangs
+NAME = Premium Linux for Enterprises
# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
Surely nobody can resist such a patch?
2.8.0?
Having two numbers for major changes is excessive, but it would be nice to keep at least one major version number for incompatible changes (e.g. syscall cleanup). I'd rather go with 3.0, 3.1,... 3.42 etc.
2.8.0?
3.12 - 3.99, then 4.11 - 4.99, then...
4.11 - 4.99
5.11 - 5.99
...
9.11 - 9.99
2) the above numbering keeps all in alphabethical order
3) 3.11 dropped for not mismatching with something from early nineties
would take us far into 22nd century -- probably into 23rd...
2.8.0?
I mean, Linux has been used for a long time; other hackers may deserve some credit too no?
And that would be more amusing than mere numbers, imagine questions on LKML: are you running Cox, Andrex or Rustyx?
Admittedly, the ordering might be a little more difficult to remember than with integers; but maybe we could sort out some easily remembered scheme. I propose the order of chronological appearance in LWN quotes of the week.