Will there be a 11.5-RELEASE ?

I realize there is no mention of it, so I am guessing the answer is no. Howeer when I read the FreeBSD project releases info, I notice for 11.x it still shows a status of "Development branch for FreeBSD 11-STABLE" and not "Maintenance branch...." like "Maintenance branch for 10-STABLE (not officially supported)" for example.

Does that suggest there will/could be a 11.5-RELEASE eventually? Just trying to decide when I should migrate my machines to 12.x path.
 
No, it only means that there’s still a release on the stable/11 branch that’s not EOL, namely 11.3 and 11.4.

I don’t know if there are plans for 11.5, but my guess would be no. Also see the Release Engineering page. It only mentions the upcoming 12.2 and 13.0, but no 11.5 anymore.
 
When to migrate to 12.x? In the past I found it safe to wait for x.3-REL. At the very time, there seem to be some issues related to 11.x OpenSSL version in base. So it might be reasonable for some to switch earlier.
 
  • Like
Reactions: a6h
When to migrate to 12.x?
If/When there's a need or requirement. For production servers as long as 11 is supported you can easily keep it that way. Certainly start testing with 12.x, so you're not thrown off a cliff when 11 goes EoL. Make sure you're prepared, you have plenty of time to work out the kinks if there are any. For desktop systems I would recommend always going with the latest versions as soon as possible. There is so much movement with regards to graphics drivers there's simply no reason to stick to a legacy release.
 
As a reminder: Since 6.x, there have generally been 5 releases from a branch, from x.0 to x.4. This means there will be no 11.5.

The only exception to the rule I mentioned is 9.x which ended with 9.3.
 
When to migrate to 12.x? In the past I found it safe to wait for x.3-REL.
I don’t see a reason to wait for x.3 (or for any other specific number). Although some people have valid points for avoiding “dot zero” releases.

Personally I don’t even wait for a release. I usually update along the stable branch, which is currently stable/12. The last update of my FreeBSD machines at home was at the end of June, when the stable branch was somewhere after 12.1 and on its way to 12.2.

I’ve been following that practice for roughly 25 years, and I never had any serious problems. But maybe I was just lucky. ;)
Before I update, I have a look at the commits of the past few days (“SVNews” can be useful for this), and if anything looks fishy, I postpone the update.

Of course: YMMV. If you’re in doubt, you can install the new version in a VM (e.g. bhyve) first and make sure it’s working for you, then update your physical machine(s). And as always, having a backup is a good idea.
 
I've had no issues at all running 12.1-RELEASE or even 12.0 for that matter but that doesn't mean that there aren't any issues but at least I haven't managed to stumble upon such.
 
I've had no issues at all running 12.1-RELEASE or even 12.0 for that matter but that doesn't mean that there aren't any issues but at least I haven't managed to stumble upon such.
When a .0 release comes out, features or devices which have relatively low usage may have new bugs or stop working entirely. Similarly, the formatting of some command output may change. You may think "who the heck tested this - we had beta1/2/3 and rc1/2/3 so this must have surely been found by now". But the number of users who actually run the betas and rcs is quite low compared to the number of users running a -RELEASE or -STABLE, so things do go undetected until users adopt the new version.

My strategy is to run -STABLE on release X and then migrate to -STABLE on release X+2. This normally works well except that in the case of 10 -> 12, 10 went EOL before 12.0-RELEASE. It normally takes me a month or two to rebuild all of my local code, install necessary ports, etc. and by that time many of the nits in the X.0-RELEASE have been sorted out, and I file PRs for any new ones I find. I then roll out the new release, starting from the least complex systems (4 nameservers) to intermediate complexity systems (a dozen or so RAIDzillas). The most complicated systems are our NOC management systems and multi-domain webservers, which can take quite some time as we have many thousands of lines of diffs against various ports. Plus, there is the issue of getting commercial 3rd-party software built on the new release. That isn't a huge issue for us as the ABI/KBI is generally stable enough that most code written for a few releases back continues to work on newer releases (I have some code built on 8.x that still works on 12-STABLE). But it is always a good idea to ask the commercial vendor for a build based on the new FreeBSD release, as it lets them know that there is active interest in FreeBSD which in turn encourages them to keep supporting it.
 
Back
Top