Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 May 2007 12:44:14 -0600
From:      "Andrew Falanga" <af300wsm@gmail.com>
To:        "John Nielsen" <lists@jnielsen.net>
Cc:        freebsd-questions@freebsd.org, Alex Zbyslaw <xfb52@dial.pipex.com>
Subject:   Re: A little bit of help understanding CVS and cvsup
Message-ID:  <340a29540705171144s1bcea909k8ede69a9bd6887ef@mail.gmail.com>
In-Reply-To: <200705171440.36371.lists@jnielsen.net>
References:  <340a29540705170804r51e4d073w9da7eaf9203e85bd@mail.gmail.com> <464C74D3.7070308@dial.pipex.com> <340a29540705171131j5ab024f4qf8957d52460cdad@mail.gmail.com> <200705171440.36371.lists@jnielsen.net>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 5/17/07, John Nielsen <lists@jnielsen.net> wrote:
> On Thursday 17 May 2007 02:31:59 pm Andrew Falanga wrote:
> > On 5/17/07, Alex Zbyslaw <xfb52@dial.pipex.com> 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
>
I figured as much, but didn't want to shoot myself in the foot, as it were.

Andy



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?340a29540705171144s1bcea909k8ede69a9bd6887ef>