Change to FreeBSD release scheduling and support period(lists.freebsd.org)
lists.freebsd.org
Change to FreeBSD release scheduling and support period
https://lists.freebsd.org/archives/freebsd-announce/2024-July/000143.html
16 comments
December releases always make me somewhat nervous. It is not fun if delivery slips into the second half of the month.
Fair point, but I'm optimistic we can make this work. Half of the "December" releases will be .0 releases and we have 6 months allocated for those so I'll make sure I allow plenty of slack in the schedule; some of them may end up happening in November in fact.
Lots of folks love tinkering through xmas - lonely for weeks at last
>the FreeBSD core team has approved reducing the stable branch
support duration from 5 years to 4 years starting with FreeBSD 15
Interesting, that is the exact opposite of what many big Linux Distros seem to be heading for. Companies would rather have a 100 year support cycles and never do upgrades at all. SUSE (I think) just announced a 12 year support schedule.
I wonder how that will work out for FreeBSD. It seems like a good idea, but I think it could hurt their commercial customers.
At the company I worked at, EOL anything on Dec will cause them to avoid it at all costs. IMHO, EOL Dates should be in the first month of the quarter, not the last month of a quarter.
Interesting, that is the exact opposite of what many big Linux Distros seem to be heading for. Companies would rather have a 100 year support cycles and never do upgrades at all. SUSE (I think) just announced a 12 year support schedule.
I wonder how that will work out for FreeBSD. It seems like a good idea, but I think it could hurt their commercial customers.
At the company I worked at, EOL anything on Dec will cause them to avoid it at all costs. IMHO, EOL Dates should be in the first month of the quarter, not the last month of a quarter.
I'm not sure that I see the issue with a December EoL; can you elaborate? There's always at least 3 months for upgrades -- it's not like we're doing a release on December 15 and saying "you need to upgrade by the end of the month".
Every company were I worked over the decades, at the end of each fiscal quarter a 'freeze' would applied. No patches or upgrades for the last month of each quarter. This "end" usually always happens in March, June, Sept and Dec where I have worked.
This is because 90% of sales occur/booked right before the end of each quarter. This means the company wants 99.(100x)9 uptime. People have lost their jobs if the system is down at this time. Also, for the end of the fiscal year, the freeze has been extended for something like 6 weeks before the end of the fiscal year.
For example, at IBM, to get a major high impact security patch applied, you need high level VP approval at Quarter End. Minor patches will never be applied. As you can guess, middle level managers never want to sign their life away. For system upgrades without security impacts, it is impossible.
Most software that needs to be update, it is almost always held off to the first or 2nd month of the fiscal period. If a company sees EOLs occurring on the last month of each quarter, they will never use that software. They will go looking for alternatives.
HTH
This is because 90% of sales occur/booked right before the end of each quarter. This means the company wants 99.(100x)9 uptime. People have lost their jobs if the system is down at this time. Also, for the end of the fiscal year, the freeze has been extended for something like 6 weeks before the end of the fiscal year.
For example, at IBM, to get a major high impact security patch applied, you need high level VP approval at Quarter End. Minor patches will never be applied. As you can guess, middle level managers never want to sign their life away. For system upgrades without security impacts, it is impossible.
Most software that needs to be update, it is almost always held off to the first or 2nd month of the fiscal period. If a company sees EOLs occurring on the last month of each quarter, they will never use that software. They will go looking for alternatives.
HTH
Huh, interesting. For many of the users I heard from, the end of December is the ideal time for doing upgrades, since they don't need to worry about system availability while people are away on their Christmas/New Years vacations.
I think this is probably fine though; it just means that the companies you mention will need to upgrade in October or November. That's why we have a 3 month overlap between when one minor version is released and when the previous minor version is EoLed.
I think this is probably fine though; it just means that the companies you mention will need to upgrade in October or November. That's why we have a 3 month overlap between when one minor version is released and when the previous minor version is EoLed.
> 3-4 BETAs
Irrelevant, but why is "BETAs" capitalised?
Irrelevant, but why is "BETAs" capitalised?
It was always THIS naming scheme. Tradition.
- 14-CURRENT
- 14.1-STABLE
- 14.1-PRERELEASE
- 14.1-BETA1
- 14.1-BETA2
- 14.1-BETA3
- 14.1-BETAN
- 14.1-RC1
- 14.1-RC2
- 14.1-RC3
- 14.1-RCN
- 14.1-RELEASE
Details here:
- https://docs.freebsd.org/en/articles/freebsd-releng/
Hope that helps.
- 14-CURRENT
- 14.1-STABLE
- 14.1-PRERELEASE
- 14.1-BETA1
- 14.1-BETA2
- 14.1-BETA3
- 14.1-BETAN
- 14.1-RC1
- 14.1-RC2
- 14.1-RC3
- 14.1-RCN
- 14.1-RELEASE
Details here:
- https://docs.freebsd.org/en/articles/freebsd-releng/
Hope that helps.
[deleted]
I think I'd be interested in seeing stats on how many people wind up living on EoL releases, because I know I have.
And, I know its higher risk for CVE exposure.
Sometimes "do a minor number upgrade, to fix this" is the price you have to pay.
And, I know its higher risk for CVE exposure.
Sometimes "do a minor number upgrade, to fix this" is the price you have to pay.
The hope is that with more frequent releases the upgrade path between minor releases will be smoother -- often in the past we've had breakage due to developers saying "I really need to get this into the tree now because otherwise I'll need to wait over a year for the next release". At some point we might change terminology to say e.g. "FreeBSD 17 update 3" rather than "FreeBSD 17.3" -- I've been saying for long time that we should think about minor updates as service packs rather than full releases.
It should be said this is mostly fine-tuning. freebsd-update is ok mostly, sure from time to time I find the CVS <<< >>> notation confusing, but thats a pretty small price to pay for something which JUST WORKS.
the disconnect between FreeBSD versions and the state of portsnap sometimes is in some ways more confusing. "sorry, you can't use ports anymore, we decided you're too old, but if you set WE_WARNED_YOU_THIS_MAY_NOT_WORK=1 it may be ok" -I don't seem able to predict when this is coming down the pipe. I am lazy and mostly live in the prebuilt binary pkg anyway so again, this is whining.
Thank you for the care taken with this thing. It's awesome.
the disconnect between FreeBSD versions and the state of portsnap sometimes is in some ways more confusing. "sorry, you can't use ports anymore, we decided you're too old, but if you set WE_WARNED_YOU_THIS_MAY_NOT_WORK=1 it may be ok" -I don't seem able to predict when this is coming down the pipe. I am lazy and mostly live in the prebuilt binary pkg anyway so again, this is whining.
Thank you for the care taken with this thing. It's awesome.
I want to reiterate the thanks as well. Updates work so much better than in the past.
Dealing with twenty files of this does get annoying.
>>>>>>>
#Fobar Version 1.1
======
#Foobar Version 1.2
<<<<<<
I'm sure I got the terms wrong. Fix this somehow. I wouldn't care if support was only two years, as otherwise, everything upgrading is seamless.
Thanks again for everything you've done!
Dealing with twenty files of this does get annoying.
>>>>>>>
#Fobar Version 1.1
======
#Foobar Version 1.2
<<<<<<
I'm sure I got the terms wrong. Fix this somehow. I wouldn't care if support was only two years, as otherwise, everything upgrading is seamless.
Thanks again for everything you've done!