5 ms·

I've been following FreeBSD development for a long time, and I've been wondering if changes to the support model would be forthcoming and would help simplify th

I've been following FreeBSD development for a long time, and I've been wondering if changes to the support model would be forthcoming and would help simplify things so that if I build on top of FreeBSD I can be guaranteed some sort of stability in the longer term. This announcement while welcome doesn't give me a really good idea of what is going to change. It would be absolutely fantastic if some examples could have been included instead of just stable/X. For example, using hypothetical released named X.0-RELEASE and Y.0-RELEASE and Z.0-RELEASE what are the branch names going to be called, how often are they going to be created, and how long are they going to be supported? How does this compare to LTS from Canonical/Red Hat? How easy is it going to be to keep up with the changes between the minor releases? What guarantees does the community have that driver modifications/fixes are not going to get stuck in -CURRENT or the next major release only, or have to be manually back-ported?

tiffanyh 12y ago
X-Istence, the announcement is very straight forward ... but for the lazy it's essentially: Starting with 11, the following will happen: * All major releases (e.g. 11) will be supported for no less than 5 years * The N+1 major release (e.g. 12) won't happen any earlier than 2 years after the previous major release (e.g. 11) is released. * Whenever a new point release is made (e.g. 11.1) all previous point releases will be deprecated after 3 months (e.g. 11.0) * All stated support timeliness for pre-11 releases will continue as stated before
- cperciva 12y ago
  11 will be supported for no less than 5 years FWIW, this was how long we typically supported releases anyway -- FreeBSD 6.x was supported from November 2005 until November 2010, FreeBSD 7.x was supported from February 2008 until February 2013, FreeBSD 8.x from November 2009 until June 2015, and FreeBSD 9.x from January 2012 until December 2016 -- but we heard from users that a promise was far more useful than a vague "well, typically...". Whenever a new point release is made (e.g. 11.1) all previous point releases will be deprecated after 3 months (e.g. 11.0) This is really the most important change, and addresses a problem we've had for a while: When a point release comes out, we have no idea how long it will be until the next point release. For both users and the security team, knowing the end of the support period relative to the arrival of the next point release (i.e., the overlap time) turns out to be more important than knowing the end of the support period relative to the start of the support period.
- X-Istence 12y ago
  Please don't call me lazy. I tried to understand the announcement and it just didn't make a whole lot of sense so I asked questions about it. @cperciva answered those questions for me in a much more pleasant way than you did. That being said, the reason I am confused is because it doesn't really change anything. Releases were already for the most part supported for 5 years, and new releases were already cut once every two years (look at 9.0-RELEASE and 10.0-RELEASE).
  - cperciva 12y ago
    it doesn't really change anything The timeline for dropping support of point releases is important. The rest is mainly about improving communication: Many users were not aware that we supported releases for 5 years, for example, because all they ever saw was the advertised "12 months" or "24 months" for point releases.
    - X-Istence 12y ago
      Yes, the understanding for how long point releases will be supported makes a lot of sense and will definitely help. The rest (5 year support timeline) was already something I understood from having followed the project for some time, I just didn't understand if this announcement changed my understanding thereof.
- vacri 12y ago
  Phrases like "will not occur before two years after" are not particularly straight-forward. I found some of the prose in this release curly and baroque; if you have to re-read a sentence a few times to get the meaning right, it's not clear language.
cperciva 12y ago
How does this compare to LTS from Canonical/Red Hat? Ubuntu has a LTS release every 2 years, which is supported for 5 years. FreeBSD will have a release every 2ish years, which is supported for 5 years. How easy is it going to be to keep up with the changes between the minor releases? It's already relatively straightforward by using freebsd-update, but work is underway to simplify this further. What guarantees does the community have that driver modifications/fixes are not going to get stuck in -CURRENT or the next major release only, or have to be manually back-ported? None. This is, after all, a volunteer project; if nobody is interested in backporting a driver, it isn't going to get backported. Also, from time to time there are new devices which require significant changes to the underlying kernel architecture (video drivers and virtual memory come to mind, for example), and those are often impossible to merge back because doing so would break internal interfaces used by third-party drivers.
- X-Istence 12y ago
  I understand that major devices will be impossible or difficult to merge back, especially if there are invasive changes. In the past though even relatively simple changes were not MFC'ed until someone asked for it, and once MFC'ed it took a long time for it to appear in a point -RELEASE. Tracking stable/ isn't for the faint of heart, and especially isn't for those of us that want to do binary upgrades. Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Rather than some of the 8+ months that have happened in the past between point releases? Thank you for clarifying cperciva!
  - cperciva 12y ago
    even relatively simple changes were not MFC'ed until someone asked for it To a certain extent that's always going to happen in volunteer projects. That said, at least on the server side, the "ecosystem" of FreeBSD-using companies with committers on staff is expanding, and they're doing an increasing amount of this sort of maintenance. The topic of how we can make sure important MFCs happen has certainly come up. Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Maybe. Certainly there is significant support for doing more frequent point releases; but some of the reason they have been so slow lately has been due to operational issues (aka. re@ juggling too many balls at once) so these policy changes aren't going to have a dramatic effect overnight, but they might contribute to things improving.

tiffanyh 12y ago

X-Istence, the announcement is very straight forward ... but for the lazy it's essentially: Starting with 11, the following will happen: * All major releases (e.g. 11) will be supported for no less than 5 years * The N+1 major release (e.g. 12) won't happen any earlier than 2 years after the previous major release (e.g. 11) is released. * Whenever a new point release is made (e.g. 11.1) all previous point releases will be deprecated after 3 months (e.g. 11.0) * All stated support timeliness for pre-11 releases will continue as stated before

cperciva 12y ago
11 will be supported for no less than 5 years FWIW, this was how long we typically supported releases anyway -- FreeBSD 6.x was supported from November 2005 until November 2010, FreeBSD 7.x was supported from February 2008 until February 2013, FreeBSD 8.x from November 2009 until June 2015, and FreeBSD 9.x from January 2012 until December 2016 -- but we heard from users that a promise was far more useful than a vague "well, typically...". Whenever a new point release is made (e.g. 11.1) all previous point releases will be deprecated after 3 months (e.g. 11.0) This is really the most important change, and addresses a problem we've had for a while: When a point release comes out, we have no idea how long it will be until the next point release. For both users and the security team, knowing the end of the support period relative to the arrival of the next point release (i.e., the overlap time) turns out to be more important than knowing the end of the support period relative to the start of the support period.
X-Istence 12y ago
Please don't call me lazy. I tried to understand the announcement and it just didn't make a whole lot of sense so I asked questions about it. @cperciva answered those questions for me in a much more pleasant way than you did. That being said, the reason I am confused is because it doesn't really change anything. Releases were already for the most part supported for 5 years, and new releases were already cut once every two years (look at 9.0-RELEASE and 10.0-RELEASE).
- cperciva 12y ago
  it doesn't really change anything The timeline for dropping support of point releases is important. The rest is mainly about improving communication: Many users were not aware that we supported releases for 5 years, for example, because all they ever saw was the advertised "12 months" or "24 months" for point releases.
  - X-Istence 12y ago
    Yes, the understanding for how long point releases will be supported makes a lot of sense and will definitely help. The rest (5 year support timeline) was already something I understood from having followed the project for some time, I just didn't understand if this announcement changed my understanding thereof.
vacri 12y ago
Phrases like "will not occur before two years after" are not particularly straight-forward. I found some of the prose in this release curly and baroque; if you have to re-read a sentence a few times to get the meaning right, it's not clear language.

cperciva 12y ago

How does this compare to LTS from Canonical/Red Hat? Ubuntu has a LTS release every 2 years, which is supported for 5 years. FreeBSD will have a release every 2ish years, which is supported for 5 years. How easy is it going to be to keep up with the changes between the minor releases? It's already relatively straightforward by using freebsd-update, but work is underway to simplify this further. What guarantees does the community have that driver modifications/fixes are not going to get stuck in -CURRENT or the next major release only, or have to be manually back-ported? None. This is, after all, a volunteer project; if nobody is interested in backporting a driver, it isn't going to get backported. Also, from time to time there are new devices which require significant changes to the underlying kernel architecture (video drivers and virtual memory come to mind, for example), and those are often impossible to merge back because doing so would break internal interfaces used by third-party drivers.

X-Istence 12y ago
I understand that major devices will be impossible or difficult to merge back, especially if there are invasive changes. In the past though even relatively simple changes were not MFC'ed until someone asked for it, and once MFC'ed it took a long time for it to appear in a point -RELEASE. Tracking stable/ isn't for the faint of heart, and especially isn't for those of us that want to do binary upgrades. Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Rather than some of the 8+ months that have happened in the past between point releases? Thank you for clarifying cperciva!
- cperciva 12y ago
  even relatively simple changes were not MFC'ed until someone asked for it To a certain extent that's always going to happen in volunteer projects. That said, at least on the server side, the "ecosystem" of FreeBSD-using companies with committers on staff is expanding, and they're doing an increasing amount of this sort of maintenance. The topic of how we can make sure important MFCs happen has certainly come up. Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Maybe. Certainly there is significant support for doing more frequent point releases; but some of the reason they have been so slow lately has been due to operational issues (aka. re@ juggling too many balls at once) so these policy changes aren't going to have a dramatic effect overnight, but they might contribute to things improving.