Version number of next LFS release

Matthew Burgess ca9mbu at
Wed Jan 15 14:41:29 PST 2003

"Gerard Beekmans" <gerard at> wrote in message
news:200301151534.03410.gerard at
> Hi guys,
> There's been some disagreement between me and Jesse what version to attach
> the next LFS version. It's either going to be 4.1 or 5.0
> My reasoning to having chosen 5.0 is that there have been some major
> most notably in the Glibc field. If the next book were to be called 4.1,
> would imply small changes were made but you could install all the new
> software and be done with it.
> However, this'll bite people in the back and make all their static
> useless unless they do the second Glibc installation with the patch, or
> something like that. But that'd be deviating from the book.
> Calling it 5.0 just shows it's a major release, you can't just upgrade and
> expect it to work. A install from scratch is recommended. A major version
> increase conveys that better than a point release.
> If anybody has some very good reasoning not to go with 5.0 but to call it
> let me know and I _might_ reconsider.

Just to add my 2 pence worth.  If all of the xml changes were the *only*
changes made to the book (along with minor package updates, such as
util-linux, man-pages, etc.) then I think 4.1 would be justified.  But, like
you said, with the major changes in glibc I'd say go for 5.0.  I believe
this is the way the majority of software packages work - minor version
releases are compatible with previous releases within the same major release
version (e.g. 3.2 is compatible with 3.1 and 3.0), but compatibility with
future major version numbers is not guaranteed.  Yes, I know LFS is not
software per se, but due to our reliance on such similar issues I think the
book should follow (and has done in the past) a similar convention.



Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list