linux-kernel - Re: From 2.4 to 2.6 to 2.7?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080715163652.GA12728@lgserv3.stud.cs.uit.no>
Date:	Tue, 15 Jul 2008 18:36:52 +0200
From:	Tobias Brox <tobias@...d.cs.uit.no>
To:	linux-kernel@...r.kernel.org
Subject: Re: From 2.4 to 2.6 to 2.7?

[Cyrill Gorcunov]
> Some areas should be distinguished:

Areas?  "Target audience groups" maybe?  Well, I'm also not a native
English writer ;-)

>	- development/stable team
>	- distros
> 	- regular users

> So we have the quite large group of people which should be considered for
> convenient versioning scheme - _regular users_. Lets say I'm a regular user -
> the most convenient scheme for me would be YYYY.r.s i think since it tells
> me - this kernel is fresh enough to be used on my shining laptop, and maybe
> it even supports all hardware I have! And at least it looks good -
> 	Linux-2008.0.0

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/