[Cyrill Gorcunov]Areas? "Target audience groups" maybe? Well, I'm also not a native English writer ;-) So, the version numbers aren't important for anyone else than "regular users"? Ok, I'm a "regular user", so then I'm qualified to comment ;-) Microsoft has attempted using year numbers in their releases, do we really want to go the same way? ;-) Well, indeed - my vote goes in the direction of YYYY.r.s. I have one concern though, such a release could easily be mistaken for beeing an actual date. Maybe better to write 2008.r1.s1 to make it explicit it isn't the release date? 2008.r1.s1 would at a glance easily give me an impression on whether the kernel version is "outdated", "mature" or "fresh". 2008.r1.s1 is easily googlable (though googling for "linux changelog 2.6.25" isn't really that difficult) That being said, is it really reasonable to assume the linux kernel will continue evolving gradually for all future? In all software, sometimes it is really needed to make some major changes, break backward compatibility and decrease the stability - and that's what the major version numbers are for. I think saying "we'll never need to change the major version number again" is roughly equivalent with "the design of Linux 2.6 is perfect". Or, maybe some years or decades down the road we'll all upgrade to something with a different name than Linux ;-) -- Tobias Brox, 69°42'N, 18°57'E --
| Lennart Sorensen | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Dmitry Torokhov | Re: 2.6.21-rc5-mm3 |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
