14.1-RELEASE EOL, Quarterly Packages

M

mer

So 14.1-RELEASE went EoL 31 Mar, basically end of quarter. I assume that next set of quarterly packages will be built against 14.2-RELEASE so one does not have to build say drm-i915kms port? and this next set of quarterly will be available June?
 
mer said:
So 14.1-RELEASE went EoL 31 Mar, basically end of quarter. I assume that next set of quarterly packages will be built against 14.2-RELEASE so one does not have to build say drm-i915kms port? and this next set of quarterly will be available June?
Click to expand...
Without to be an expert but I think June is wrong. Instead it will be July.
As I understand it the quarterly package updates are Q1 January - Q2 April - Q3 July - Q4 October.
Soon the drm-kmod not working discussion will ease off but as fernandel already mentioned it will start early June all over again.
For me - unless 14.3 has the super cool must have immediately new feature - I upgrade 3 month later to avoid the hassle.
 
fernandel said:
and in 3rd June 2025 is coming out 14.3_RELEASE and we will again use packages from 14.2 or use ports.
Click to expand...
Fernandel, yesterday I bought two SSDs SiliconPower (32GB each) for $5 each, ---> stripeZFS --->> installed 14.2 --->> compiled
drm-61-kmod from source, because from binaries it still causes a black screen. I'll make snapshots and BE and I can live. It doesn't matter when something comes out. If something crashes, I'll restore it myself quickly and successfully. For me, as a newbie, it was useful to use the ZFS property - mount the entire BE as a FS bectl mount ... and work with it. I made a mistake in the syntax of /etc/rc.conf , forgot to make a copy, but I attached it and fixed the situation. I didn't know that you can easily fix an error when the system crashes...
 
USerID said:
Fernandel, yesterday I bought two SSDs SiliconPower (32GB each) for $5 each, ---> stripeZFS --->> installed 14.2 --->> compiled
drm-61-kmod from source, because from binaries it still causes a black screen. I'll make snapshots and BE and I can live. It doesn't matter when something comes out. If something crashes, I'll restore it myself quickly and successfully. For me, as a newbie, it was useful to use the ZFS property - mount the entire BE as a FS bectl mount ... and work with it. I made a mistake in the syntax of /etc/rc.conf , forgot to make a copy, but I attached it and fixed the situation. I didn't know that you can easily fix an error when the system crashes...
Click to expand...
I do not have a problem with drm-kmod when I have two repositories for packages - FreeBS and kmods and for my laptop from 2021 I do not want to use ZFS and I do not want anymore to build ports. And as meaw229a wrote I will do the same or wait for version 15.
 
mer said:
So 14.1-RELEASE went EoL 31 Mar, basically end of quarter. I assume that next set of quarterly packages will be built against 14.2-RELEASE so one does not have to build say drm-i915kms port? and this next set of quarterly will be available June?
Click to expand...

If we can trust https://pkg-status.freebsd.org/?type=package&all=1 then all the builds of 14.x quarterly that started since 1st April are now 14.2 (filter on "build" using the search box).

The only doubt I have is that pkg-status still (also) shows builds that started in 2024, so _something_ is wrong.
 
  • Like
Reactions: mer
fernandel said:
Are "defaults" latest, please?
Now is more than 2000 done just about 33000 more. It is hard work.
Click to expand...
I think "defaults" on that page must be "latest" in FreeBSD.conf, but it's confusing when the default in FreeBSD.conf is quarterly...

I've never seen anything documenting this.
 
Barney said:
“EOL” on a free, open source software platform. You can’t make it up 🤦‍♂️
Click to expand...
You instead expect the free software developers, working on this stuff in their spare time, to support their software for even longer than the multi-million dollar corporations are able to?

Unless you mean we can fork it and maintain old versions ourselves, in which case then I do agree. Nothing can truly be EOL.
 
www.freebsd.org

FreeBSD Security Information

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org

Key paragraph:
Each release is supported by the Security Officer for a limitedtime only.

The designation and expected lifetime of all currently supportedbranches and their respective releases are given below. TheExpected EoL (end-of-life) column indicates the earliestdate on which support for that branch or release will end. Pleasenote that these dates may be pushed back if circumstances warrantit.


So while one can argue about the exact definition of "End Of Life" in relation to open source software, I was using the term in the exact same way that the FreeBSD release team does.
 
USerID said:
Fernandel, yesterday I bought two SSDs SiliconPower (32GB each) for $5 each, ---> stripeZFS --->> installed 14.2 --->> compiled
drm-61-kmod from source, because from binaries it still causes a black screen. I'll make snapshots and BE and I can live. It doesn't matter when something comes out. If something crashes, I'll restore it myself quickly and successfully. For me, as a newbie, it was useful to use the ZFS property - mount the entire BE as a FS bectl mount ... and work with it. I made a mistake in the syntax of /etc/rc.conf , forgot to make a copy, but I attached it and fixed the situation. I didn't know that you can easily fix an error when the system crashes...
Click to expand...
I had to compile drm-61-kmod from ports as well due to the off monitor after loading the binary from pkg. My GPU is AMD 6750XT Navi for reference.
 
This is why I stick to ports, and don't bother with packages. With -RELEASE versions having a relatively short shelf life, I sometimes question the wisdom of maintaining distinct package repos that are separated by architecture (like amd64, z390, aarch64, and the like) AND by release version (14.1, 14.2, 14.3, 13.2, and the like)... Just the amd64 arch having separate release versions - think about the amount of storage that the Foundation needs to rent and otherwise procure! amd64 has repos for at least 5 versions, so does aarch64, and so does z390. With each version/release-tagged repo taking up a couple terabytes easy, amd64 alone needs 10 TB for repos! So does aarch64, so does z390, this adds up to 30TB of storage just for the pre-compiled packages!

And on top of that, we do need mirrors. So there's 30 TB to mirror all over the planet.

This is the combinatorial explosion in everybody's face. Not quite as bad as bitcoin, but still.

The Foundation does have limited resources, so one kind of has to expect some turnover at the source. Outdated stuff out, updated stuff in. That's how EOL happens, Barney ... even in Open Source. It's not out of question to have some unofficial archives, or to get your own copy of the correct git repo and go back in time - but that takes skill, time, and effort.
 
Well "things" seem to be settling out with respect to packages. I always do "upgrades across releases" into a new BE, which allows me to easily upgrade all the packages. Today it picked up 14020000 versions of DRM stuff, so activated the new BE rebooted, kldload new DRM bits and so far no issues.
 
14.1-RELEASE is a snapshot. It’s EOL after the first -STABLE patch

mer said:
Well "things" seem to be settling out with respect to packages. I always do "upgrades across releases" into a new BE, which allows me to easily upgrade all the packages. Today it picked up 14020000 versions of DRM stuff, so activated the new BE rebooted, kldload new DRM bits and so far no issues.
Click to expand...
Why? They’re all working why potentially introduce new issues for a bunch of code I don’t need? Do you upgrade your server's firmware every time there’s a new release? No, you update it if you have a problem and need a fix.
 
Barney said:
Why? They’re all working why potentially introduce new issues for a bunch of code I don’t need? Do you upgrade your server's firmware every time there’s a new release? No, you update it if you have a problem and need a fix.
Click to expand...
Your hardware, you decide whether to install the latest updates or not. There's no obligation and no real pressure to upgrade every time there's a new release. Some users prefer to have smoother upgrades, so they are willing to put in the time and effort to do it often. Yeah, there are benefits to doing it like that - those benefits don't necessarily make sense for other users.

I don't upgrade until my installation of Firefox says, "I can't handle the Internet any more, upgrade me or else!". This is the moment that prompts me to clean out my machine and install up-to-date software from scratch. Reasoning behind such a policy - I don't want to sink time into upgrading every time there's a new release. And no, I don't want a constant flow of updates, either.
 
Barney said:
14.1-RELEASE is a snapshot. It’s EOL after the first -STABLE patch


Why? They’re all working why potentially introduce new issues for a bunch of code I don’t need? Do you upgrade your server's firmware every time there’s a new release? No, you update it if you have a problem and need a fix.
Click to expand...
14.1-RELEASE by itself sure (I'd argue it's a tag), but EOL as defined by the release engineering team means the initial release gets patched for security issues, hence new tags 14.1-RELEASE-p1,p2...pN.

When 14.1-RELEASE goes EOL, there are no more security patches for it, packages are not built against it anymore (typically only an issue for things like drm-kmod) so unless you are upgrading from source for base and ports, one eventually should want to upgrade to a new release to obtain security patches.
In theory, one could maintain their own source tree of FreeBSD 5.0-STABLE, manually apply any security related items found between that and 14.X-RELEASE, manually update a ports tree to include new versions of needed applications and any security fixes then build that ports tree against your updated 5.0 tree.


Of course your systems you do what you want, but give others the same courtesy of administrating their systems the way they want.
 
mer said:
manually update a ports tree to include new versions of needed applications and any security fixes then build that ports tree against your updated 5.0 tree.
Click to expand...
At least in recent years, ports tree omits supports (conditionals) for EoL'ed releases. So tracking what's omitted and manually re-applying would be required. Personally, term EoS (End of Support) seems to be better fits than EoL (End of Life).
 
T-Aoki said:
At least in recent years, ports tree omits supports (conditionals) for EoL'ed releases. So tracking what's omitted and manually re-applying would be required. Personally, term EoS (End of Support) seems to be better fits than EoL (End of Life).
Click to expand...
The tracking and manually applying to source is exactly what I meant. Doable? Sure, but a lot of effort. At some point a feature that "I really really need" like hardware support for a specific device is available in a new release so you upgrade at that point. Lots of people kept running Windows95 way beyond it's supported life.

I agree that End Of Support may be a better term, but at least EoL is defined in the release engineering documentation.
 
T-Aoki said:
Would be no for most of individuals including myself, I think. Maybe well experienced and skilled team of developers for full time work would be wanted to do so, especially for older releases.
Click to expand...
And that is exactly what happens in a lot of commercial envrionments. Simple example is Red Hat. Pick a release, say version X. Throughout it's supported lifetime RedHat has people that cherry pick stuff from newer versions (bug fixes, security etc) and manually apply them to version X. Redhat also "locks" the version at X, with patch numbers and build numbers. So yep they have teams of people doing this. Why? Contracts, usually with government agencies that are "approved for version X" so you are obligated to provide fixes for version X until government approves version Y (where Y > X).

It's not fun work but it will pay the bills and it can be interesting backporting things.
 
mer said:
And that is exactly what happens in a lot of commercial envrionments. Simple example is Red Hat. Pick a release, say version X. Throughout it's supported lifetime RedHat has people that cherry pick stuff from newer versions (bug fixes, security etc) and manually apply them to version X. Redhat also "locks" the version at X, with patch numbers and build numbers. So yep they have teams of people doing this. Why? Contracts, usually with government agencies that are "approved for version X" so you are obligated to provide fixes for version X until government approves version Y (where Y > X).

It's not fun work but it will pay the bills and it can be interesting backporting things.
Click to expand...
Can't be good ROI here... especially if you're stuck on something obscure, while everyone else has moved on to something that is widely standardized, and will do the job just as well.
 
astyle said:
Can't be good ROI here... especially if you're stuck on something obscure, while everyone else has moved on to something that is widely standardized, and will do the job just as well.
Click to expand...
I don't disagree but if you've ever dealt with government contracts, things can be very particular and getting new versions approved is a non trivial task.
Heck look at the US military and some of the firearms. Inventory says something is a "Model M1911" it gets rebuilt as a "Model M1911" not as a "Model M1911A1".

I'm not saying "it's right" or "it's good" more, it "just is".
 
You must log in or register to reply here.
Back
Top