Change to FreeBSD release scheduling and support period

Cath O'Deray

Cath O'Deray

 
Check your mailboxes :) and subscribe to freebsd-announce, if you haven't already done so.

Also announced by Colin Percival cperciva@ on social media.

The quarterly schedule, and reduction from five years to four, look good to me.
 

Attachments

  • 1720667271407.png
    1720667271407.png
    66 KB · Views: 136
While I can understand the reasoning from the developer side, this is not good news for operations. Reducing the support time for minor and major releases simply increases administrative effort and increases the chance of breaking something during an update.

Bottom line: not happy about this.
 
Any minor or major version upgrade can break something. It does not happen often, but when updating a box from 13.2 to 13.3 I got a bad kernel and had to go to the physical box. Not a biggie in this case, but sometimes servers a hundreds kilometers away. Now the number of times of such an upgrade is increased.
 
My opinion:
Trying to put out point releases more often is a good thing. Why? Typically going to be a smaller changeset, so easier to test prior to release.
Colin's argument about "...just one more thing" is solid: trying to cram just one more often shortchanges the testing and leads to breakages. Sometimes major, often minor.

Reduction to 4 yrs from 5: Overall very good thing. Keeps the project moving forward, new hardware support included, less effort on developers "do we MFC this or not".

If a business doesn't like the 4 year support, they could simply git clone the repos and do support in-house. I'd posit that years 4 and 5 are primarily security patches.
And yes, I understand that it also means there won't be prebuilt binary packages after 4 years.
 
mer said:
And yes, I understand that it also means there won't be prebuilt binary packages after 4 years.
Click to expand...
I am sorry, but I don't follow.

As I understand the last major decision for the changes of the future of FreeBSD is the ports system, as we know it
cd /usr/port/of/my/choice
make install
[fetch, compile, compile, compile... - done. installed.]

is going to become obsolete.
I'm not really happy about it, but since I'm doing not much installation by ports, so be it.

Now, there also will be no more
pkg install swofmychoice
[fetch, install - swofmychoice installed.]
anymore?

So we're going to end up like this Linux?
sudo github pull ...
sudo github fetch ...
sudo github get ...
sudo add this...
sudo do that...
sudo ....
sudo ....
sudo make install
[compile,...Error, error, error. Aborted!
Dependency crap....something]
*sigh*
sudo github pull something
sudo github fetch something
sudo github get something
sudo add this something
sudo do that something
sudo ....
sudo ....
sudo make install
[compile,...Error, error, error. Aborted!
Dependency crap.... something else]
😤
sudo github pull something else
sudo github fetch something else
sudo github get something else
sudo add this something else
sudo do that something else
sudo ....
sudo ....
sudo make install
[compile,...Error, error, error. Aborted!
Dependency crap.... something completely else]
🤬

?

:eek:
 
%pupil -sceptical said:
I am sorry, but I don't follow.
Click to expand...
For any given release, since the support period is reduced from 5 yr to 4, prebuilt binary packages for any given release also EOL at 4 yrs.
I pointed that out because there have been threads here basically "I tried to update my packages for version 7.0 and there are none available. Why won't the project keep packages for every release?"
 
So I simply misunderstood what you ment (and overreacted.)
Thanks for clearing this up.

So, as I understand now:
Less tattered different versions-tree to maintain, more consistence, more energy for on the ones which will maintained.
Makes sense. I appreciate that.
Thanks.
 
  • Like
Reactions: mer
The change relates to the base operating system (FreeBSD), not the ports collection.

From Navigating FreeBSD’s New Quarterly and Biennial Release Schedule (the related FreeBSD Foundation blog post):

1722418253465.png


Note:
  • extensive overlap between 14 and 16
  • minimal overlap between 15 and 17.
Visualise:
  • 16.4-RELEASE in March 2030
  • 16.5-RELEASE in September 2030
  • and so on.

For the ports collection, consequences of the four-year support period (for FreeBSD) should be good.

"… We haven't done a great job of supporting releases in their 5th year... stuff gets broken in ports and nobody notices for a long time, difficult side channel attacks don't get patched, et cetera."

– and so on.
 
Cath O'Deray said:
For the ports collection, consequences of the four-year support period (for FreeBSD) should be good.

"… We haven't done a great job of supporting releases in their 5th year... stuff gets broken in ports and nobody notices for a long time, difficult side channel attacks don't get patched, et cetera."
Click to expand...
This is a big reason why I felt the move to 4 yrs was good.
 
mer said:
Trying to put out point releases more often is a good thing. [...]
Click to expand...
I tend to agree, but a lot will depend on its actual implementation and execution. However, I'm encouraged by the presentations of Colin Percival and Gordon Tetlow: 2024 FreeBSD Developer Summit: Release Engineering updates

FreeBSD users have to adjust to the new scheme that will likely be more predictable. Corporate users have to update and resynchronise their update schedule; that may even be in an environment that is change averse.


Why is this in "Off-Topic"?
Seems very much on topic and at the core of FreeBSD!
 
Well, there seems to be some confusions related with pkgbase.
  • pkgbase is for providing base as multiple pkg, more fine-grained compared with current release tarballs (like base.txz, kernel.txz, ...).
  • /usr/src and /usr/ports (default places) are kept on provided as usual, means, source tree and ports tree are not going to be vanished, as they are still needed to build pkgs for base and ports respectively.
Installer (currently, bsdinstall) should be modified or replaced with an alternative to use base pkgs instead of current release tarballs on switching to pkgbase, but would be no changes for ports pkgs.

Note that I've not trying pkgbase myself, as I'm using src upgrading.
 
  • Like
Reactions: mer
T-Aoki very valid point. Ports tree is now git, if an entity (person, company, whatever) is tied to a base version that has been EoL'ed, any and all updates are on them. Cut a tree off the last 12.x release, do the work of MFC to your desired release. Ports may be tied to base version (drm stuff), but maybe not, just git pull on latest and keep local modifications (some ports may wind up erroring on old version of base).
A lot of companies do this, but at some point the question "Why are we supporting Windows 3.11 when the current version is Windows 11?" must be asked and answered.
 
The problem with this is not the 4 years. The problem is the new release each half year.

Up to now, a new release appeared about once a year. That did mean, upgrade, find the undocumented changes and regressions, spend about three months worrying, testing, fixing whatever - and then have some nine months where the systems would just run, and other useful work could be done.

Now we have this hassle every six months - and no, it will not be less troublesome.

In more ancient times the release upgrades were very much desired, because they would improve or fix important things which were urgently needed.
But more recently the upgrades did not contain much noteworthy things and mostly nothing one would need for normal server operation. Most often there is no reason at all why one would want to upgrade - we're only forced to do it because the ports compilation would no longer work with the old release.

So I said, okay, if you want to release twice a year, then make the support interval accordingly longer, so that people who have no technical reason to need the upgrade, can skip every other one.

The outcome of this suggestion was the usual: this might be considerable, but it is not in our responsibility, and is someway complicated. I.e. the same answer I always got when talking to officials since back when I lived under pharao in ancient Egypt.
 
PMc said:
The problem with this is not the 4 years. The problem is the new release each half year.

Up to now, a new release appeared about once a year. That did mean, upgrade, find the undocumented changes and regressions, spend about three months worrying, testing, fixing whatever - and then have some nine months where the systems would just run, and other useful work could be done.

Now we have this hassle every six months - and no, it will not be less troublesome.
Click to expand...
That's exactly my fear, too, and why I put my concerns a bit more dramatic-naiv.

Short:
It makes no sense to just produce newer versions in shorter times,
just for to produce newer versions in shorter times.

If - and that's how I want to understand Colin Percival - the goal is
'just' to reorganize the resources,
so they are splitted less because of fewer versions to maintain,
for that having more resources to produce higher quality on the focused ones,
which also will deliver a more predicatble, planable release-schedule,
which may also decrease the time-span between releases,
then I am 100% behind that.

Long:
I fear there is lots of pressure coming from those 'bleeding-edge-surfers'. I don't know if there is actually a term for the who always must have the most recent version available, impatient checking several times daily, if there is something to update, and then immediatly update it right away.
That has nothing to do with 'bug patches', or 'security'.
It's mostly simple frantic - in my opinion.

I am running 13.3, because besides 14.0 and 14.1, that is the RELEASE for production.
And I can tell you today when I will upgrade: Two to three weeks after the release of 13.4 (app. october.)
To 13.4.
I am a simple only-user.
I am not doing any development on FreeBSD.
This is not some kind of experiment for me. This is my machine I do all my work on.
For that it has to work stable, reliably, and trustworthy, and nothing else.
So I am running RELEASE, only.
Why shall I struggle with some yet-not-finished, not ready to be released for production version yet?

Does this makes me feel insecure about my system?
No.
I daresay 99% of safety issues come from having a bad password, running software you don't know its origin, don't check the sha256/512-checksums, click on dubious e-mail-attachments, stay on dubious websites with an outdated browser not wearing a condom, being too open/careless with permissions, having stuff installed you don't use/need thus increasing attack surface for no reason,
and of course naturally when there actually is a vulnerability detected, e.g. in ssh, openssl, pf, bash, or whatever, and this you don't update to the fixed version.

But not because of I have gimp-2.10.38,1 installed instead of gimp-2.10.38,2.

And if it's fixed, it's fixed in all supported versions.
It doesn't matter if I run 13.3, or 14.1. As long as they are supported, the fixes are available.
I subscribed the security-announcement mailing list; there are not that many things one needs to be really concerned about.
One may not fear not having the most recent version of every app immediatly may a wide open attack gate.

On the contrary, the gimp I knew from fifteen years ago looked exactly the same, and did exactly the same.
With one major difference: It never crashed.
Nowadays besides libreoffice gimp is the most unstable software I have installed, seems to work without a crash for more than a couple of hours by pure luck only.
And no patch/update/upgrade fixed that in the last five years.
Only the type of crashes changed.

I know libreoffice/gimp is not FreeBSD.
That was just an example.

A couple of years ago the one or the other new version of FreeBSD delayed for a few months.
Explanation:"We're sorry, guys, but there are several issues we don't cope with yet."
To me it was very convincig chosen the right OS.
This actually produced my confindence, really increased my trust I have into FreeBSD.

Before that I used Windows, and Linux (mostly SuSe and Ubuntu).
Updates every day. Updates, Updates, Updates... "A new update is available. Do you..." :rude:
No! I do not want. But I have to, because you shit will not stop annoying me, until I did. 😤
Always the fear: "Now which shit will not work properly anymore? What will now start to crash?"
I barely seen any useful improvement, mostly changes of UI. Just to relearn things, again.
Never seen a single bug bothered me was fixed, but other bugs came.

I do know that development is needed.
I do know patches fix bugs, as also (some) updates, and (some) upgrades may also bring improvement.
My point is:
Every engineer knows:
Any change is a potential risk for new bugs.
So updates do not always improve things only.
There always is a real risk to actually worsen things, especially when too many updates are released within too short time-spans.

We just saw the prove for that in large again with this CrowdStrike desaster,
that an update may even cause more damage than if it was prevented (maybe in this case even worse than a malware attack.) One may better waited a couple of days, before update (And I bet there are companys experienced exactly this.)

Take your time to do it right, and test things - then release!

Don't bother me with a new version of some lib with lots of dependencys everytime some newbie on the project had corrected a typo within a comment.
And then the rest refuses to work, because all other depending Apps have to be updated, only now to use the new version number of the lib.

(True story. But don't ask me for details; too long ago.)
I once really did checked it (Linux). Actually compared the new version of some lib with its former version.
The only difference I found was the version number, only. Nothing else changed.
But lots of crap refused to work suddenly because of this 'update'.
And I din't can't wait several days, until everything else may be also updated, and may function again as I was used to. I had a dead-line for delivery my finished work the very next day. And not the will to do, what I formerly did in this situation several times before: Completely reinstall my whole system, again, except this time not doing the recent update.
Yes. This is bogus!
But what to do else? When you cannot remove the update again, neither can wait, nor rely on the needed updates are being delivered in time to make the system work again, so you can finish your work on time.
I tried something. I simply edited that lib. Simply renamed the file, and tinkered with emacs, changed its version number to the former one.
Voilá, everything was working fine again.
I finished and delivered my work on time.
That counts for me.
Not having v0.3.4.5.4b_3.0.0.1,0.a,0.1 instead of v0.3.4.5.4b_3.0.0.1,0.a,0

This update-madness not only pisses me.
Way worse it lowers my trust into the according system.
Massively, deeply, and lasting.
That's why I put my fear in such post like this one, again.
"😱 ... not again!! No! Please, no!! Guys, calm down!"

I don't want the newest.
I want reliability, and stability.
And I guess especially producers of embedded systems see it similar.
I upgrade/update/patch when it's needed to do so, not because of there is a new version available.

That's what I appreciate of FreeBSD.
By now updates came reasonably.

And that there also is at least the possibility to remove possible 'bad' updates, even to downgrade, again.
Falling back to the former state, which at least worked stable and reliably, is major, crucial point to guarantee work can be done with it.
Only going forward, only, and if there was a bug in the update you have to wait for the next update, that may come, one not knows when, not knows if the bug will even be fixed, or if even new ones are delivered...just wait - that's crap!
And just because Windows (I do know that in newer versions there is a chance to remove some updates again [just to prevent corrections from bean-counters]) and (most) Linux, doesn't mean this the reference to be done so everywhere.

FreeBSD in some things lacks behind Linux' bleeding edge. For me not in things I miss or care. Of course, personal taste, absolutely.
But for that I have (most of the time) a consistent, reliably working system I have trust and confidence in.
Way - way - more than into Linux, or Windows.

And I simply do not want that to change.

My fears come up again everytime when I read here:
"Where is the new version! Guys, you promised yesterday! You are one day behind schedule!! Release!!! Faster!!!!
I already installed 15...when 16 is released?!...17, 18,... faster! faster!!"
Why? For what?!
Guys! Relax!
Where does this stress come from?
What do you need some not-yet-finished prototype, so unreliable, unstable for?
I cannot imagine you are all developing on it.
And I think developers know how the situation is.

But if nobody of the senior-ones here, the established, the mature ones, the experienced, the real engineers - and there are lots of those here - don't relevate things, calm things down, I feel the impatient ones might win some day if nobody says something about it.
So I feel the urge to post, that there may also be another side, another perspective.
Maybe I'm mistaken, but I feel I'm not the only one.

I am not the guy who sleeps on the sidewalk just to be one of the very first ones getting the most recent toy.
I am an engineer with real experience in real industry's product development.
And others here may certify it even more:
Never buy a product, that's just released.
Wait at least until the worst flaws, and bugs are being corrected (if.)
Doesn't matter if it's automotive, electronics, household equipment,..., or software.
Keeping time schedules is way more important than to produce quality - at least in consumer's.
Because there are enough monkeys grabbing greedy for any new crap without concerns.

But real engineers want to have and want to do things properly, and right.
I hope, wish, and still believe, here they are in the majority.
 
The only time anyone MUST upgrade is when the release they are currently running goes EoL. Even then, no one forces them to; if they want to build everything from source including ports, they can.
Right now, regardless of how many point releases per year, you have patch releases. Patch releases are for security issues. Do you have to actually upgrade to that patch release? No. In fact I go and look at what CVEs are being addressed, read the CVEs to see if there are any mitigation strategies (such as tweak a config setting and restart service), then also decide if it actually applies to my specific situation (such as if it needs physical access, that ain't happening without me knowing). After all of that I may choose to not apply a patch level.

Same thing applies to point releases. Take the time to evaluate "Does this have anything I MUST have?" If yes, upgrade. If not, don't upgrade. Just keep in mind you may need to walk releases (as in running 11.x, must stop at 12.x before going to 13.x)

Anyone that has developed software, especially large codebases, realizes a smaller change set is easier to code review, easier to regression test. Yes, often the process gets ignored or worked around, but that is more a fault of people.

I am not trying to convince anyone the new way will be better overall, simply because talking about "release" always ends up in dogmatic arguments.

My opinion only, I feel the changes are good. Agree, disagree, no big deal to me.
 
mer said:
The only time anyone MUST upgrade is when the release they are currently running goes EoL. Even then, no one forces them to; if they want to build everything from source including ports, they can.
Click to expand...
Wrong!
That is exactly what they can NOT do. When the release is EoL, the ports cannot be built from source anymore, because the Makefiles fail to work.

mer said:
Same thing applies to point releases. Take the time to evaluate "Does this have anything I MUST have?" If yes, upgrade. If not, don't upgrade.
Click to expand...
And keep all your obsolete old ports running, with all their now published security flaws? Really?
 
PMc said:
And keep all your obsolete old ports running, with all their now published security flaws? Really?
Click to expand...
If actually there are no obsoleted-version-specific fixes exists and you are building ports locally, all you need for ports should be reverting the Mk/bsd.ports.mk part of commit to sunset the version. An example here.

Yes, there usually are many ports dropping supports upon it, but if any of ports actually using is not at all included, there are no harm at least for a while.
 
PMc said:
Wrong!
That is exactly what they can NOT do. When the release is EoL, the ports cannot be built from source anymore, because the Makefiles fail to work.


And keep all your obsolete old ports running, with all their now published security flaws? Really?
Click to expand...
Cool down.
If you update the ports tree, the onus is on YOU to make any modifications needed to actually build the ports.
Point releases are the base system, NOT ports. Skipping a binary upgrade of a point release in the base system does not prevent you from updating ports with the exception of things like drm-kmod.

You are also missing the bigger point.
Any time there is an upgrade available, you should evaluate what that is gained by upgrading, why the upgrade and make a decision to actually do the upgrade or not.

This is exactly what I meant by dogmatic camps.
 
Apparently the new release schedule only addresses one end of the chain. It leaves some major pain points unsolved, among them:
  • There's demand for both fast track (new hardware drivers, WiFi stack...) and maintenance only (security and bug fixes) releases. This new schedule is detrimental for the latter.
  • We still have to maintain two major version releases with almost the same target group.
  • Ports have to be compatible with two major release versions.
  • No maintenance only branch of ports (security and bug fixes), per major release.
Not all of these issues can be addressed, we have limited and mostly voluntary workforce. But it could be valuable to explore some ideas, like:
  • Relegate the older major version (13.x currently) to maintenance, patch updates only, no more minor releases.
  • Frequent minor releases for the newer major version (14.x), make this the feature update branch.
  • Decouple ports from base where feasible, e.g. use an llvm from ports as the "base compiler" for ports.
I'm sure there's more ways to improve the life of both users and developers.
 
You must log in or register to reply here.
Back
Top