[lfs-dev] LFS announcement format change in LFS News.

akhiezer lfs65 at cruziero.com
Mon Sep 4 01:48:14 PDT 2017

> Date: Sun, 3 Sep 2017 22:24:25 +0100
> From: Ken Moffat <zarniwhoop at ntlworld.com>
> On Sun, Sep 03, 2017 at 09:19:56PM +0100, Richard Melville wrote:
> > On 3 September 2017 at 19:42, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> > 
> > > Richard Melville wrote:
> > >
> > >> Is there any chance of arriving at some consistency?  Maybe either: "LFS
> > >> <version number> Stable Release" or, as the latest states: "LFS <version
> > >> number> Release", for those that are not release candidates, obviously.
> > >>
> > 
> > Yes, thanks for that, but if it is edited manually then why cannot the
> > original format of "LFS  8.1 Stable Release" be maintained instead of "LFS
> > Stable Version 8.1 Release"?  To me, it's not logical and it's hard to
> > follow.  Also, it doesn't follow the existing pattern.  Doing it the new
> > way we now have:-
> > 
> > LFS  Stable Version 8.1 Release
> > LFS 8.1-rc2 Release
> > 
> > Wouldn't the following be better and be in line with preceding entries:-
> > 
> > LFS 8.1 Stable Release
> > LFS 8.1-rc2 Release
> > 
> > I think it looks better, it scans better, it's more easily readable, and it
> > follows the existing pattern.
> I think people might have more sympathy if we could understand why
> you do this, 

It's in the first post of the 'thread' (but yes, as noted, the 'thread'
gets broken repeatedly: so even tho the subject-line has 'Re: ', it is
not always as readily-apparent as it should be, as to where the first
post of the 'thread' actually is).

> and what the benefits to LFS might be.

The much-vaunted educational value could perhaps be enhanced by adding
an example of doing-it-right - e.g. per prev post fr akh today re known
reliable loc/fmt for rel info, for scripters.

>  OTOH, we might
> not - I have a lot of my own scripting to check if I'm using the
> same versions of packages as BLFS, and I frequently have to tweak
> those scripts because of changes.

If neither the upstream nor downstream/user/your dtds (or equiv) have
changed, then there is no requirement for scripts to change; as, it is
then only needing to detect content change.

And often dtd/equiv changes necessitate only a fairly simple once-off
remapping of structure.

> In particular, surely most casual users look for the latest release,
> whilst those who are more interested will follow the development
> book and know what is happening ?
> ??en, confused why this is important to you

'??' indeed. Again, ref orig post in 'thread'.



More information about the lfs-dev mailing list