On Thursday 17 May 2007 02:31:59 pm Andrew Falanga wrote:
> On 5/17/07, Alex Zbyslaw <[EMAIL PROTECTED]> wrote:
> > Andrew Falanga wrote:
> >
> > You can find a description of release tags in the handbook.
> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html
> > and also a description of -STABLE and -CURRENT
> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.
> >html.
> >
> > Later bits in that section also describe the update procedure *even if
> > you are updating to a RELEASE./RELENG rather then CURRENT or STABLE*.
> >
> > A brief description of the strings in tags is a follows:
> >
> > CURRENT == bleeding edge
> >
> > STABLE == merely leading edge
> >
> > RELENG == what you are calling "stable"; a release plus security patches
> > only
> >
> > RELEASE == sort of you are calling stable, exactly what was released
> > (not recommended since it lacks any security patches)
> >
> > The latest release is 6.2, so the tag you want in your supfile is
> > RELENG_6_2.  That string won't be in any supfile on your system.  It's
> > impossible for it to be, since that would require predicting what will
> > be the latest release at the point in the future when you chose to
> > upgrade :-)
> >
> > In technical terms, CURRENT is the top of the main development trunk,
> > and is often referred to with a leading number (e.g. 7-CURRENT), but the
> > number does no more than denote the numeric tag that will be applied
> > when the next branch is made.  Once 7.0 starts being created, CURRENT
> > will be 8-CURRENT.
> >
> > STABLE is the latest branch.  Code here will become the next Release.
> > Moving code from CURRENT to STABLE, involves a CVS merge operation and
> > is often referred to as MFC - merge from CURRENT.
> >
> > RELENG is a branch created when a specific release is made.  It denotes
> > the latest code on that branch, but the only changes made will be
> > critical security fixes.
> >
> > RELEASE is just the point on the RELENG branch which is the actual code
> > which was released on the Release CDs.
> >
> > --Alex
> >
> > PS
> >
> > Be really nice if all this info was clearly in the FAQ, and the FAQ was
> > searchable apart from the whole website.  As things stand, a search for
> > "stable" returns precisely nothing, which can't be right.
>
> Thank you for the detailed description.  Just one last question for
> you and the list, what sort of heart ache can I expect to encounter if
> I use the label RELEASE_6_2 in my supfile on a system that is 6.0?  I
> need to upgrade a 6.0-RELEASE (no patches) system.  Will I encounter
> compiler problems (that is, I'm using a compiler that's older than I
> should for 6.2), or similar?  Or, should the upgrade be just as smooth
> as the run through I just completed on a non-critical notebook running
> 6.2-RELEASE (or rather, it was running 6.2-RELEASE, now it's
> 6.2-RELEASE-p4)?

In my experiences upgrades that don't cross major version boundaries are 
relatively painless. I haven't done a 6.0-6.2 upgrade, but I've done multiple 
6.0-6.1 and 6.1-6.2 upgrades, and both were quite minor so I don't think 
doing it in one go would introduce any problems. Compiler changes in 
particular will typically only happen across major versions. Nothing like 
that going on with 6.x. Should be smooth, just with a longer mergemaster 
step.

JN
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to