> From: Bruce Dubbs <[email protected]>
> Date: Mon, 9 May 2016 09:14:56 -0500
> Subject: Re: [blfs-dev] Versioning -- [Was: GCC 6 annoyances]
>
> 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?
>
Overall, I'd say that for public/customer/users/downstream, by far
the most info is conveyed by a (tautology alert!) well-considered
X.Y.Z... scheme.
I'd suggest (~strongly) that the next B/LFS _does_ have a
public-release version of 8.0 (or just '8'): this is on the assumption
that 'B/LFS' is being regarded as a single 'product'; and on the
assumption that it will ship with added/removed software such that
(a substantial number of) users of B/LFS 7.9 _will_ need to make
significant changes at their end (this incl >~1 categ of
dev/desktop/av/server/&c users).
So if next B/LFS will have one/more of e.g.:
--
* gcc 6, no gcc 4/5, and gcc 6 doesn't readily (via flags/&c) behave
like gcc 4/5 ;
* kde5, no kde4, and kde5 has no easy kde4-compat mode;
* qt5, no qt4, and qt5 has no readily-usable qt4-compat mode;
* &c&c.
--
; then 'definitely' that's a major-version bump for B/LFS.
With that type of versioning scheme: I'd expect at current rates
you'd have at least one major-ver bump per 12/18 months (again,
that's not a target to be partic hit or avoided - instead, it just
reflects accurately versioning of the overall product).
Timestamps/dates/&c I'd say should at most be in internal-version
that would be at most a superset of public-release version: see
e.g. points 9 & 10 of the semver.org page for some examples; and of
course cf the currently-used 'svn-${TS}'-type practice for b/lfs.
((
Some other 'good' versioning examples are: seamonkey 2.x, apache 2.x,
sendmail 8.x, bind 9.x, dovecot 2.x, samba 4.x, nfs 3.x/4.x, ... ;
& the vast majority of packages in b/lfs. OTOH: what version would
firefox or linux (kernel) 'really' be; maybe guesstimate from ESR/LTS;
or only know by staying closely-familiar with each such package;
or maybe the devs could save everyone the hassle by having proper
versioning.
If one was maintaining a product that uses, say, firefox as primary
interface: then you'd normally not have the product's versions follow
whichever firefox versions you're snapshotting for use - not even
if you're following only ESRs. And similarly for kernel/LTS. You'd
instead rely on (presumably) your close knowledge of such products,
what their 'proper' versions 'really' are, and know when to change
your own product's minor/major versions, and to what values.
Likewise for B/LFS: you wouldn't do a major-ver bump 'just because',
say, linux/kernel went from 2.x to 3.0 ; you'd know instead that it
wasn't really a 'proper' major-ver difference. Likewise _if_, say,
gcc started doing 'puff-piece' version-numbers: but in the meantime,
as-is gcc 6 (and iff no gcc 4/5 behav avail) does 'justify' a major-ver
bump for b/lfs.
))
What if 'proper'-(internal-)versioning LFS got ('naturally')
out-of-sync with 'proper'-(internal-)versioning BLFS ? That'd be fine,
and is really a moot point: for, it's the B/LFS overall 'product'
that we're considering the versioning of here; and the working
assumption for the foreseeable future is that b/lfs are developed &
released together as the two parts of the overall product; and so it
is not artificial to release, say, B/LFS 8.0 if the major-ver bump has
been necessitated from only the lfs side, or only from the blfs side,
(or from both). And if some way _was_ wanted to track internal vs
external/public versions, then again the aforenoted examples/points
9 & 10 in the semver.org page, could be used quite straightforwardly.
rgds,
akh
--
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
