4 ms·

Change to FreeBSD release scheduling and support period

31 points by cperciva 2y ago

ggm 2y 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.
- cperciva 2y 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.
  - ggm 2y 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.
    - workingdog 2y ago
      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!
cowsandmilk 2y ago
December releases always make me somewhat nervous. It is not fun if delivery slips into the second half of the month.
- cperciva 2y 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 2y ago
  Lots of folks love tinkering through xmas - lonely for weeks at last
hyperbrainer 2y ago
> 3-4 BETAs Irrelevant, but why is "BETAs" capitalised?
- cperciva 2y 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.
  - vermaden 2y ago
    After using FreeBSD for so much time I can not get used to 'OpenBSD-current' naming :)
- vermaden 2y 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/ https://docs.freebsd.org/en/articles/freebsd-releng/ Hope that helps.
deleted 2y ago
[deleted]
jmclnx 2y 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.
- cperciva 2y 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".
  - jmclnx 2y 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
    - cperciva 2y ago

31 points by cperciva 2y ago

ggm 2y 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.

cperciva 2y 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.
- ggm 2y 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.
  - workingdog 2y ago
    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!

cowsandmilk 2y ago

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

cperciva 2y 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 2y ago
Lots of folks love tinkering through xmas - lonely for weeks at last

hyperbrainer 2y ago

> 3-4 BETAs Irrelevant, but why is "BETAs" capitalised?

cperciva 2y 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.
- vermaden 2y ago
  After using FreeBSD for so much time I can not get used to 'OpenBSD-current' naming :)
vermaden 2y 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/ https://docs.freebsd.org/en/articles/freebsd-releng/ Hope that helps.

deleted 2y ago

[deleted]

jmclnx 2y 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.

cperciva 2y 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".
- jmclnx 2y 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
  - cperciva 2y ago