> 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). ---- Refs: -- 1) http://semver.org/ 2) http://www.jvandemo.com/a-simple-guide-to-semantic-versioning/ 3) http://www.sitepoint.com/semantic-versioning-why-you-should-using/ 4) https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e 5) https://en.wikipedia.org/wiki/Software_versioning ---- rgds, akh -- -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
