Change to FreeBSD release scheduling and support period

https://lists.freebsd.org/archives/freebsd-announce/2024-July/000143.html

by cperciva • 2 years ago

31 15 2 years ago

lists.freebsd.org

ggm2• 2 years ago

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.

cperciva5• 2 years ago

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.

ggm2• 2 years ago

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.

cowsandmilk• 2 years ago

December releases always make me somewhat nervous. It is not fun if delivery slips into the second half of the month.

cperciva5• 2 years ago

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.

szundi• 2 years ago

Lots of folks love tinkering through xmas - lonely for weeks at last

hyperbrainer• 2 years ago

3-4 BETAs

Irrelevant, but why is "BETAs" capitalised?

cperciva5• 2 years ago

Heh. The builds we do are called X.0-ALPHA#, X.Y-BETA#, X.Y-RC#, and X.Y-RELEASE. And I got used to capitalizing "BETA", I guess.

vermaden2• 2 years ago

After using FreeBSD for so much time I can not get used to 'OpenBSD-current' naming :)

vermaden2• 2 years ago

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.

jmclnx2• 2 years ago

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.

cperciva5• 2 years ago

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".

jmclnx2• 2 years ago

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

Change to FreeBSD release scheduling and support period

Related Stories