> From [email protected] Wed Aug 7 19:19:31 2013 > Date: Wed, 07 Aug 2013 12:03:00 -0500 > From: Rob Landley <[email protected]> > To: akhiezer <[email protected]>, > BLFS Development List > <[email protected]> > Subject: Re: [blfs-dev] Planning ahead > > On 08/04/2013 05:05:56 AM, akhiezer wrote: > > > Date: Sat, 03 Aug 2013 18:07:43 -0500 > > > From: Bruce Dubbs <[email protected]> > > > To: LFS Developers Mailinglist <[email protected]>, > > > BLFS Development List <[email protected]> > > > Subject: [blfs-dev] Planning ahead > > > > > > We have reached a milestone. The SVN versions of both LFS and BLFS > > are > > > now up to date. There are no major outstanding issues that need to > > be > > > fixed. > > > > > > There are a couple of minor changes that I have to LFS, but those > > will > > > be committed soon, but are not critical. KDE is slightly out of > > date, > > > but a new version is due anyway in the next two weeks. > > > > > > Of course, upstream will continue to release additional updates and > > we > > > need to stay on top of that, but keeping up is a lot less problem > > than > > > getting caught up from being behind on literally hundreds of > > packages. > > > > > > With that in mind, I would like to freeze LFS (mostly) on August 15 > > and > > > release LFS-7.4-rc1. The target date for LFS-7.4 will be 1 > > September. > > > During the freeze period, some packages may be updated, but not gcc, > > > binutils, or glibc. Any update in the freeze period will be > > considered > > > by the impact to the rest of the books - both LFS and BLFS. > > > > > > In that two week period, beyond normal fixes, I propose to start > > > rebuilding BLFS and marking packages for lfs74. Shortly after the > > LFS > > > release, I'd like to produce a 'stable' BLFS-7.4 with all packages > > in > > > BLFS tested against the new LFS. Then sometime in September we can > > > release BLFS-7.4. > > > > > > Comments? > > > > > > > > > Could you (or whomever) take the current-revision (or similar) > > blfs-svn, and > > cut a 'blfs-svn-rNNNNN-lfs73_allchecked', with xml src and with > > rendered html > > & pdf, plus relevant auxiliary stuff like bootscripts/patches/&c, and > > put it in > > its own directory under '/downloads/....' on the web? Like was done > > for > > blfs/lfs-72 back in early Nov 2012. > > s/_allchecked/-rc1/ > > That's what a release candidate _is_. >
- not sure what meaning are you intending to convey there. Could you clarify? Thanks. AIUI, it's intended that there's not going to be a formal blfs-7.3 release: as such, a '-rc1' label tacked on after the '-lfs73' part like you seem to suggest, is perhaps not pertinent; whereas the perhaps-more-stolid 'lfs73_allchecked' reflects better the state. The present blfs may be viewed as a release-candidate for blfs-7.4 : but, again, I'm not sure what your suggested 'blfs-svn-rNNNNN-lfs73_allchecked' -> 'blfs-svn-rNNNNN-lfs73-rc1' brings to the table? rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
