CURRENT, STABLE, RELEASE --> meet PRERELEASE !

GlitchyDot

GlitchyDot

CURRENT, STABLE, RELEASE --> meet PRERELEASE !
freebsd142stable.png


freebsd143prerelease.png
 
Interesting... looks like RC (Release Candidate) is now called PRERELEASE????

I'm not a fan of the name change, but it's good to know this bit of info.

If possible, I would prefer to stick to the traditional RC1/RC2/RC3 tagging convention.

I wonder, what was so broken that the new tagging scheme is supposed to fix? Basically, why did the name change even happen?

If somebody can link to a blog or something that explains the rationale, that would be nice.
 
great, yet another label nobody will read the description for... :rolleyes:

And what's the difference between a "release candidate" and a "prerelease" build? Or is this just a rebranding of the RC (or worse: BETA) builds? why?
 
fff2024g said:
can we upgrade 14.2 to 14.3 from freebsd-update upgrade ? thanks.
Click to expand...
FreeBSD comes with good documentation, your question could have been answered fast, consulting the freebsd-update(8) manual.

In short, it is possible if the branch name arrives at BETA (ALPHA builds are not included in the FreeBSD Release schedule.):

freebsd-update(8)
Code: 
BINARY UPDATES AVAILABILITY
     Binary updates are not available for every single FreeBSD version and
     architecture.

     In general, binary updates are available for ALPHA, BETA, RC, and RELEASE
     versions of FreeBSD, e.g.:
           FreeBSD 13.1-ALPHA3
           FreeBSD 13.1-BETA2
           FreeBSD 13.1-RC1
           FreeBSD 13.1-RELEASE
     They are not available for branches such as PRERELEASE, STABLE, and
     CURRENT, e.g.:
           FreeBSD 13.0-PRERELEASE
           FreeBSD 13.1-STABLE
           FreeBSD 14.0-CURRENT
 
astyle said:
I'm not a fan of the name change, but it's good to know this bit of info.
Click to expand...
Name changes didn't happen. The upcoming next release names are on with the FreeBSD release engineering process.

PRERELEASE is the name after the the so called code slush in STABLE. Next are the BETAs, then, when the releng/14.3 branch is created from stable/14, the RCs, then RELEASE. See the article down below for all the processes and all the names.

sko said:
And what's the difference between a "release candidate" and a "prerelease" build? Or is this just a rebranding of the RC (or worse: BETA) builds? why?
Click to expand...

See article FreeBSD Release Engineering
 
T-Daemon said:
PRERELEASE is the name after the the so called code slush in STABLE. Next are the BETAs, then, when the releng/14.3 branch is created from stable/14, the RCs, then RELEASE. See the article down below for all the processes and all the names.
Click to expand...
Thanks; so PRERELEASE builds were already a thing? I must have missed them for the last 10 years - I always only noticed BETA and RC builds...

The fact that 'PRERELEASE' comes before BETA makes it even worse for all those folks with an attention span shorter than a squirrel on coke that just download a random image that "sounds good" instead of reading *a single sentence* above the links to the installer images...
But changing the nomenclature would cause confusion and chaos for the 99% users which can read and/or are using FreeBSD for years - so I guess we should just accept the fact that some people have to be left behind.
 
T-Daemon said:
Next are the BETAs, then, when the releng/14.3 branch is created from stable/14, the RCs, then RELEASE.
Click to expand...
stable/14 -> STABLE, then it becomes PRERELEASE just before releng/14.3 is branched off. Then releng/14.3 is branched off first, and the releng/14.3 branch changes to BETA1, BETA2,..., RC1, RC2,..., and finally RELEASE.

Code: 
---- 14/stable --- 14.2-STABLE ---> 14.3-PRERELEASE ----> 14.3-STABLE ---->
                                                    \____ releng/14.3 ---> 14.3-BETA1 -- 14.3-BETA2 --- 14.3-BETAx --- 14.3-RC1 --- 14.3-RC2 --- 14.3-RCx --- 14.3-RELEASE

sko said:
Thanks; so PRERELEASE builds were already a thing? I must have missed them for the last 10 years - I always only noticed BETA and RC builds...
Click to expand...
That PRERELEASE tag only happens in the stable branches, if you've never tracked a stable you would never have seen them.
 
SirDice said:
That PRERELEASE tag only happens in the stable branches, if you've never tracked a stable you would never have seen them.
Click to expand...
Oh, i thought it was a mistake named PRERELEASE hence my posting :) but seems to me its a thing in STABLE.
So 14.3 PRERELEASE is ok to download and use ?
Because once in a while i see there are some issues with STABLE iso`s to download ... i mean you can download them but not able to install them and usually if its 2 versions, older one is not installable as well.
 
GlitchyDot said:
So 14.3 PRERELEASE is ok to download and use ?
Click to expand...
If you want to track -STABLE, yes. If not, no, just wait for the first betas of 14.3 to be available.

I myself often track -STABLE for one or two machines, but I'll start off by installing a -RELEASE and just use the source to get it to -STABLE.
 
I finally understand the rationale, somewhat.

That still looks like an over-abundance of tags.

My take is, yeah, it's good to have internal organization, but maybe just not publish so many iso's with tags that are meant to aid development? If someone wants to and has the skill, they can roll their own anyway. I know that people are rather impatient, but maybe that impatience can be directed towards development of actual skills?
 
I typically already have downloaded an -RELEASE installer. Don't see the point of downloading another image, which by the time you download it is already old. -STABLE is a constantly moving target, snapshots are just that, a specific point in time.
 
SirDice said:
I typically already have downloaded an -RELEASE installer. Don't see the point of downloading another image, which by the time you download it is already old. -STABLE is a constantly moving target, snapshots are just that, a specific point in time.
Click to expand...
So basically you install -RELEASE and than go with kernel update from source and you use -STABLE, you build the kernel and once reboot - you have -STABLE ? or i`m missing something ?
 
SirDice said:
I typically already have downloaded an -RELEASE installer. Don't see the point of downloading another image, which by the time you download it is already old. -STABLE is a constantly moving target, snapshots are just that, a specific point in time.
Click to expand...
I find your method odd. You have an outdated RELEASE installation image, install a new system with it, then upgrade the system to STABLE from source.

Surely you have a regularly updated Git deep clone of the source tree on one of your systems, why not use that clone to create installation images in the desired branch with the latest patch-level?

There is such a Git deep clone (main) on my system from which I create other (ZFS) clones and checkout different branches, install in ZFS boot environments, NFS share the built source to other systems, build installation image (.iso, .img) for VMs. I have installed test VM systems with the latest patch-level installation images.

kernel, base, src .txz distribution files from image builds are used for jails, for example.

To reduce build time, when possible, WITH_META_MODE is enabled. To avoid overwriting the object directory when switching branches, ever branch has its own source tree directory (dataset).
Code: 
/usr/src-14.2
/usr/src-14.3
/usr/src-main

/usr/obj/usr/src-14.2
/usr/obj/usr/src-14.3
/usr/obj/usr/src-main
 
T-Daemon said:
I find your method odd. You have an outdated RELEASE installation image, install a new system with it, then upgrade the system to STABLE from source.

Surely you have a regularly updated Git deep clone of the source tree on one of your systems, why not use that clone to create installation images in the desired branch with the latest patch-level?
Click to expand...
It takes the same amount of time to go from any -RELEASE to the latest -STABLE compared to a -STABLE snapshot to the latest -STABLE. Still have to fetch the sources, still have to build(7) world.

T-Daemon said:
To reduce build time, when possible, WITH_META_MODE is enabled. To avoid overwriting the object directory when switching branches, ever branch has its own source tree directory (dataset).
Click to expand...
Sure, works for consecutive builds and can definitely be a time-saver. But we're talking about a new system, new build. It has to do a full build first before WITH_META_MODE would be able to skip parts that have already been built previously.
 
You must log in or register to reply here.
Back
Top