Bruce Dubbs wrote:
> DJ Lucas wrote:
>
>> Bruce Dubbs wrote:
>>
>>> I have added a new milestone, 6.4, for the current effort.
>>>
>
>
>> Yeah, actually. 6.4 sounds good to me.
>>
>
> OK, I have fleshed out the description of 6.4 and 7.0.
>
> http://wiki.linuxfromscratch.org/lfs/roadmap
>
> I've set a tentative target date of 6.4 as November 1 with the limited goal of
> updating all packages to latest stable releases.
>
> For 7.0, the tentative target date is March 31, 2009 with the goals:
>
> * Add x86_64 64-bit instructions
> o Still to be decided if a pure 64-bit or mixed 64/32-bit system should
> be
> targeted
> * Add introduction to Linux Standards Base
> * Update packages to latest stable releases
>
Cool.
>> Errata shouldn't sit around for 2 or 3 months, it should be addressed by
>> a new micro release in the release branch if the changes are not too
>> invasive. Take for instance the Perl-5.8.8 security patch. Micro package
>> revisions can also take place here.
>>
>
> That seems reasonable. It
> would not be hard to branch a 6.3.1 from 6.3 and commit changes to that as
> appropriate. I'm not sure what the release procedures should be.
Probably just use tags at that point since it is only in maintenance mode.
> Do we do a
> -rc1, etc for a minor errata change? I am thinking that would be overkill.
I agree.
> I
> suppose that a message that the branch is ready to the -dev list would be
> enough
> to decide if it's ready and then go through the normal process of building
> the
> book in the various formats, updating the web site, and making the
> announcement
> would be appropriate.
>
>
Include something to the effect of it being a bugfix release or point
release and that changes are only for security fixes or other minor errata.
> As an aside, how do we handle the change log? Do we leave in all the changes
> form 6.2 to 6.3 and add the changes for the point release to the top, or do
> we
> just put in the changes made in the point release.
>
>
We currently have a "What's new since the last release" page. The first
line on that page says "Below is a list of package updates since the
last release of the book."
How about addin an {H2} for each version? I haven't looked at LFS
sources to see exactly how that would work yet.
Since it is only a point bugfix release, the changelog should still
include the changelog from the previous release IMO.
>
>
Added the PM to future for now so that people see it there.
> There is nothing stopping an editor from branching for experimental purposes
> like Jeremy did with his pure 64-bit version. It doesn't have to be done at
> the head of the -dev version.
>
That depends on it's intended target for inclusion, but most likely,
this will be trunk to minimize the amount of merge issues when it comes
back for inclusion. I can't think of an example where it would be
appropriate to branch from next release target, but who knows.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
