akhiezer wrote:
Date: Fri, 6 May 2016 19:57:34 +0100
From: Ken Moffat <[email protected]>
Subject: Re: [blfs-dev] GCC 6 annoyances
On Fri, May 06, 2016 at 10:38:03AM -0500, Bruce Dubbs wrote:
.
.
Speaking of the next release, I'm tempted to call it 8.0 using
Linus'
rationale: it's just time for that. It's been 5 years since 7.0.
Thoughts?
To me, that sounds very like treating it as a decimal. At least
linus only rolls the version somewhere around .20. Or we could
join the firefox/chrome version fight - new number for every
release ;-)
But it is only a number, even on those days when we want to call it
666.
I'd say that a major-version increase looks likely to be justified:
but not for 'just because', 'itchy feet', 'just meaningless numbers',
"fear of (big) numbers", 'me too', &c 'reasons'.
The reasons for going to 8.0 would include any one or more of e.g.:
dropping KDE4; dropping Qt4; dropping gcc 4/5; switching to systemd
[goto ver '-500'?]; substantial reworking of boot scripts; change to
another init system; &usw.
The rationale is that you would be making major backward-incompatible
changes to the ~'public ~api' of the OS (since, e.g. the newer
KDE/Qt/gcc/&c are so very different from the dropped or switched-from
stuff).
Note that (yes, they are not Os's): glibc has been 2.x since ~1997;
binutils has been 2.x since at least 1996 (when it was at 2.7); X
has had major-ver 11 since 1987, and X11R7.x started in 2005; linux
(kernel) is still really 2.x or arguably at most 3.x .
It's not too difficult to have thoughtful, meaningful versioning for
an OS; why do all that work and then flick an essentially thoughtless,
meaningless label on the result.
Give your users/customers some indication of the magnitude of how much
will they have to change at their end in order to use your new product:
yes, READMEs &c will/should contain the details; but a proper version
number gives useful immediate at-a-glance information.
Internally here, for two OS's ((one based on *nix/bsd/linux, the
other on plan9; with eventual-aim in mind of a single line)), we use
essentially what is currently-'fashionably' being labelled as (wait
for it ... (sigh)) 'semantic versioning'; tho' we don't expect it
to be a miracle cure like some seem to think is being claimed (ref
e.g. github ref, '4)', below). Note also that it does not preclude
use of timestamps, checksum(-part)s, &c in version labels (ref
e.g. points 9 & 10 of ref '1)', below).
If B/LFS did versioning like this then in practice it likely would
never reach as high a minor-ver as .10 (tho' it is not an aim to reach
or not exceed any particular arbitrary number); and its major-rel
number would likely be markedly and justifiedly higher than 8,
while not being inflated or set brainlessly, inanely (tho' again,
with no artifical practices).
Thank you for the thoughtful post. I'll note that most of the issues you
present are for BLFS and not LFS. The reason we went to LFS 7.0 was
because of a complete rewrite of the boot scripts. BLFS just followed
when we had enough developer time to release 7.4 -- between 6.3 and 7.4 it
was a rolling update of the development system only.
Your comments about glibc and binutils is very apropos. I suspect the
reason gcc makes major changes is because they tend to break things when
the change the defaults. Commercial distros have a different motivation.
They are a part of marketing and have codewords as well as version
numbers. I note that some now use dates -- e.g. Ubuntu 16.04 Xenial Xerus
or kde applications 16.04.x.
Our timed releases actually would fall into the date method. What do you
think about {,B}LFS-16.09?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
