Solved Quarterly and Latest Ports Branches

I have read the below and wanted to get more insight.

4.4.2. Quarterly and Latest Ports Branches​

The Quarterly branch provides users with a more predictable and stable experience for port and package installation and upgrades. This is done essentially by only allowing non-feature updates. Quarterly branches aim to receive security fixes (that may be version updates, or backports of commits), bug fixes and ports compliance or framework changes. The Quarterly branch is cut from HEAD at the beginning of every (yearly) quarter in January, April, July, and October. Branches are named according to the year (YYYY) and quarter (Q1-4) they are created in. For example, the quarterly branch created in January 2016, is named 2016Q1. And the Latest branch provides the latest versions of the packages to the users.

The Latest branch provides the latest versions of the packages to the users.
Mostly around this. Is this the Latest stable version of the package? OR the latest tested version, beta version. What is the criteria for "latest". In general I am looking for what is the most up to date, stable, and secure version of any package.

So based on quarterly it sounds more stable but not more up to date. Seems also like Security fixes are in both branches. In short is "Quarterly" the same as "Latest" 3 months ago with security patches?
 
Mostly around this. Is this the Latest stable version of the package? OR the latest tested version, beta version. What is the criteria for "latest".
It's not about the latest stable version of a port or package, it's about the version that happens to be in the ports tree at that time. Some ports, Jenkins for example, have 2 ports, one is the LTS version and the other is the latest version (devel/jenkins vs. devel/jenkins-lts). But this is because Jenkins itself is released in two version, one that's kept updated constantly and a long term supported (LTS) version. For almost all other ports it's just the latest version that's available for that particular port (assuming the port maintainer keeps up with upstream releases).

In short is "Quarterly" the same as "Latest" 3 months ago with security patches?
Yes. Sort of. It depends on when you look. In January for example Q1 is branched off. At that point in time latest en quarterly are the same. While quarterly is kept in a 'frozen' state (besides the security updates), latest will continue to move forward. At the end of March, just before Q2 is branched off, quarterly would indeed be 3 months older than latest. The quarterly branch is considered 'stable' because it has very little changes over the three month period. The 'stable' in this context refers to the amount of changes, not it's 'fitness to run'.
 
Is this the Latest stable version of the package? OR the latest tested version, beta version. What is the criteria for "latest". In general I am looking for what is the most up to date, stable, and secure version of any package.
So what is the real difference between Latest and Quarterly?
Time, and use? Less testing by the userbase? Are they both considered Stable or is Latest considered Beta/Dev/testing (whatever non production use term)?
 
So what is the real difference between Latest and Quarterly?
Quarterly is more or less 'frozen' for three months while latest has daily, even hourly, updates.

Are they both considered Stable or is Latest considered Beta/Dev/testing (whatever non production use term)?
This really depends on the individual port, the maintainer and how upstream releases their code. The port usually just follows whatever upstream releases. That can be stable, beta, or bug riddled developments. Some ports do have specific -devel versions. A nice example is cad/kicad and cad/kicad-devel. But again, this is how the upstream KiCad code is available.

What you must understand is that the third party software, ports, are largely a community effort. Ports management just tries to keep the ports tree, as a whole, functioning. There are several groups of volunteers that are responsible for the larger ports (KDE, Gnome, Xorg, etc) that consists of many individual ports. So there is some structure and a lot of effort is made to make those "stable" (as in it's fitness to run). But RedHat or Canonical for example have hundreds of developers on their payroll to test, fix and keep things updated, FreeBSD doesn't have that.
 
So "latest" is in general not all stable.
It is but you're trying to extrapolate the status of an individual port to the ports tree as a whole. And it doesn't work that way.
So Quarterly is better because of Time and use.
Quarterly is a snapshot of latest taken once every three months. Nothing more.
 
It is but you're trying to extrapolate the status of an individual port to the ports tree as a whole
Yes I am. There should be Development and Stable. I understand Stable in Coding is relative. What I am looking for is Where is the "Stable" side. I wasn't clear earlier in am not interested in ports I am using Packages. If that changes things.
And it doesn't work that way.
What is best for a Production Server? of the 2 choices? or is there another choice I have not seen?

I am assuming wrongly there is a "stable" path?
 
I wasn't clear earlier in am not interested in ports I am using Packages. If that changes things.
Ports build packages. Everything starts with a port. No port, no package. Changes happen in ports, then the build clusters start building packages from that (have a look: http://pkg-status.freebsd.org)

What is best for a Production Server? of the 2 choices? or is there another choice I have not seen.
It depends on how often you want to run updates. The quarterly branches are nice if you just want to have something working without much maintenance. But you're going to face potentially massive changes every time a new quarterly branch is made (and no guarantee anything within that branch is 'stable' at that time). With latest there's always something that needs updated (it's more like a constant rolling release). As a third option you can set up your own repositories. For a client I've set up custom repositories in order to maintain about 30 servers. I've done the same for my home network. That way I'm never depending on the availability or stability of individual packages and I keep full control over when and what gets updated. I get to set the default MySQL/Mariadb version, default PHP version, default Ruby version, etc. I can also be assured all servers are running the exact same version of all packages that are installed. I can revert changes, or even insert my own local patches/fixes. Setting up your own repository is surprisingly easy. There are two good tools for this, ports-mgmt/poudriere and ports-mgmt/synth. Poudriere is what the FreeBSD clusters are running, Synth is used by DragonFlyBSD. Both can be given a list of ports (you don't have to build everything, i.e. all 42.000+ ports/packages, you build what you need) and a set of options and they'll go to work building packages from those ports. This obviously takes some time and effort (bigger, "fatter", build servers help) but you get a lot of flexibility in return.
 
It depends on how often you want to run updates.
Stable once every month at least and or as needed for security fix.
no guarantee anything within that branch is 'stable' at that time
Scary.. So there really is no Production Stable with FreeBSD?
As a third option you can set up your own repositories.
So you do this because the Mainline repos are not Stable? Also because you dont need to use a lot of bandwidth and the other reasons you mentioned. Wouldn't it be better if they just put in a process for Applications to be considered stable. Is this more related to how development with the OS is structured?
Setting up your own repository is surprisingly easy.
Is there a step by step guide? I tried Synth once it took hours and hours to compile.
bigger, "fatter", build servers
General recommendations? CPU, Memory, disk space.

Thanks for helping and listening.
 
I think one of the key things is we don't know what you want or what you need or what your systems do.

So no-one can give you blanket one-off "best" advice - it so much depends on your specific requirements.

There are no guarantees under any OS - any major upgrades of software need checking of release notes, testing on test systems, careful deployment etc.

If you are running MySQL then there was a big jump between 5.6 and 5.7 (and now to 8.0). If you use PHP, there was a big jump from 5 to 7. You had - on any OS - to test your applications, change settings, test MySQL performance, etc, and in the PHP example, potentially change a lot of code. And that's regardless of operating system. If you don't use either of those things, then you've got a couple of huge updates that you can ignore.

I think current advice is to use quarterly packages. You'll get security patches. But some quarters, there might be - depending on what you use - a bit of a jump if major software goes from one version to another. Another example would be Python.

It's the same with a build machine - it depends on what you need to build. It sounds like if you need Rust, you are going to fail with less than 8 Gb of RAM. But if you don't need Rust, you won't. How fast do you want the builds to go? If speed is more important than money, buy the gruntiest CPU you can with lots of cores. Buy the fastest NVME disks, get PCIe v. 4 and a Threadripper CPU, and loads of RAM. But I don't think you'll like the price for that lot - but it would be the "best" machine for doing so.

Get a test machine, use quarterly packages on it, see how it goes for a while and see how it works for your set-up.

I do that (have a test machine that I test updates on), and have a few production FreeBSD boxes with PHP, MySQL, Apache - they've been rock solid for years with no major issues. But I always try any new upgrade on test machine(s), wait a few days/week, then run the same steps on production. But I do that for any OS. FreeBSD itself (in my experience) has been rock solid, conservative and works well. Some of the applications on it have needed quite a bit of work during migration from one version to the next (e.g. MySQL, PHP).
 
Scary.. So there really is no Production Stable with FreeBSD?
You're now again ignoring the fact that ports are merely copies of common open source projects. This isn't on FreeBSD, they're merely following whatever the open source project in question has to offer.

And yes, reality doesn't always look nice: there is no production stable in open source because that in itself only caters to companies and that's the last thing which open source projects keep in mind - generally speaking - (it also depends on which side of the fence you're on).

Generally speaking: relying on the ports collection boils down to relying on the individual open source projects.

Wouldn't it be better if they just put in a process for Applications to be considered stable. Is this more related to how development with the OS is structured?
Once again: FreeBSD as an OS (or project for that matter) has nothing to do with this. The ports collection is pretty much unrelated to the OS (to a certain degree).

Also: how exactly would you determine something to be "stable" if you're dealing with hundreds of individual and completely separate projects?

Honestly, when in doubt I'd say rely on packages and stick to that. Using ports can be a time consuming issue, and well... unless you really need the flexibility to apply specific changes then there's really no need for any of this. Personally I'd recommend not to rely on a build service such as Synth but maybe rely on something sparse like ports-mgmt/portmaster, for the simple reason that it doesn't steer you into an arcane way of working. But still, building ports can be a time consuming effort, and it won't be useful for everyone.
 
Once again: FreeBSD as an OS (or project for that matter) has nothing to do with this. The ports collection is pretty much unrelated to the OS (to a certain degree).

Also: how exactly would you determine something to be "stable" if you're dealing with hundreds of individual and completely separate projects?
I think on Linux, though, you get say Ubuntu X, and the ports are "frozen" into that release of X. There are lots of backporters, and they will patch the version of PHP that shipped with X for as long as X is supported. So if X has PHP 5.6, then it will have 5.6 forever, and people will patch PHP 5.6.

If you want PHP 7.x on X, you have to install it yourself.

Then Ubuntu Y comes out (the new major release) and it will have PHP 7.2 for 5 years (or whatever.) And security patches will be backported and applied to 7.2. If you want PHP 7.4 or 8 - you'll have to install it yourself.

So when you move from X to Y - that's when you'll have the migration pain of major ports being upgraded. You never escape that pain, but can maybe defer it a bit longer. BUT it means you have to do more work if you want to move to the next version of a port (e.g. from PHP 5.6 to 7.4).

That's how I think it works - maybe that's the model the OP is thinking about?
 
I think one of the key things is we don't know what you want or what you need or what your systems do.
Totally get that. Which is why I am asking general questions.
There are no guarantees under any OS
True and I get that. Here is what I am asking. When a Software developer or a software company Releases software. They general release what they believe is the Stable Version to the world. Which Branch or repo or release is that on FreeBSD? Not looking for perfection looking for the General available production version, not the developmental/testing/alpha/beta version.
You had - on any OS - to test your applications
I get this as well. I want to do this on what is considered stable by the developer/OS/company..

You're now again ignoring the fact that ports are merely copies of common open source projects
I am not really. I just dont understand FreeBSD jargon. I came from Linux. These Open source project release a master version it's what they consider stable. This what am looking for. In a general example Debian has stable - testing - unstable https://www.debian.org/releases/. What is the equal on FreeBSD? I want stable not testing and not unstable.

another example Exim is on version 4.94 as stable https://www.exim.org/.
Apache is on 2.4.46 as stable release.
Are these Quarterly or Latest or Neither.
relying on the individual open source projects.
I have relied on them for years.

Also: how exactly would you determine something to be "stable" if you're dealing with hundreds of individual and completely separate projects?
Well assume you have seperate locations where that code is stored like Stable - Testing - Unstable based on the status of the code from the other project. I dont know as I am new to FreeBSD.

I'd say rely on packages and stick to that.
Yes I want this. What is or is there a most stable area to get this in FreeBSD?

That's how I think it works - maybe that's the model the OP is thinking about?
In general yes

Like FreeBSD 13 is not "Stable" So I won't use that.

FreeBSD 12.2 the quote Stable branch. I think you all call it RELEASE
Most confusing is STABLE which seems to be Development.

Sorry if I am being weird with the question. I just dont get the jargon.
 
Scary.. So there really is no Production Stable with FreeBSD?
Welcome to the wonderful world of open source. Not only are the ports(7) external projects to FreeBSD, but many software/utilties shipped with FreeBSD are external projects, incorporated/imported into the base regularly, then pinned to that revision & only security fixes patched in. E.g. from the manpage of xz(1): [...] YYY Minor version. Even numbers are stable. Odd numbers are alpha or beta versions.
So you do this because the Mainline repos are not Stable?
This is the standard policy throughout the industry. The reason is that you want to pin the orchestre of software you're using to specific revisions, of which you know they're playing nicely together. Just like a movie's director picks his/her actors.

Because of the fact that the ports tree follows upstream (in most cases), and that means there are no "stable" versions, unless the port's maintainer decides to do cherry picking; few to none do that, because it costs much time. Some ports do not have a maintainer at all...

Another reason is that you might want to build some ports with specific options applied; the default options choosen by the maintainers usually are conservative choices and in some cases important features are left off. An example SirDice mentioned a few days ago: sysutils/syslog-ng can log to a DB, but that knob is off in the default options.
Wouldn't it be better if they just put in a process for Applications to be considered stable. Is this more related to how development with the OS is structured?
Configuration & revision management (incl. testing) is a wide field of it's own. Big organisations have their own department for that, with plenty of machines in their test lab; there are even university professors who have specialized in that field.
Is there a step by step guide? I tried Synth once it took hours and hours to compile. General recommendations? CPU, Memory, disk space.
The more CPUs the better, then you can build in parallel (if the makefiles are written correctly). In general, RAM is a minor issue; but as usual, there are notable exceptions: e.g. some parts of LLVM need huge portions of RAM to compile itself. Disk space is good and a compiler cache will make use of it (devel/ccache). If you have several machines with the same compiler version, you can add devel/distcc. On ports-mgmt/portmaster: don't use it. ShelLser's recommendation is bogus. Period. This is not a matter of personal opinion, but the choice between right & wrong. Read that thread about poudriere, IIRC it's a howto.
Thanks for helping and listening.
You'll help 2. Read either way.
 
Here is what I am asking. When a Software developer or a software company Releases software. They general release what they believe is the Stable Version to the world.
No, wrong assumption. Not in the open source universe. Many open source projects have become so popular that their developers could found a company to sell support (& changes or add-ons to meet special requirements) to their commercial customers. The effect is that releases to the rest of the world are shiny new & thus, buggy. I.e., non-paying users are non-paid testers. Take it or leave it.
Which Branch or repo or release is that on FreeBSD?
Concerning the ports: none. For the FreeBSD kernel & base: The release revisions. IIRC, you can stay on 11.x-RELEASE for about a year from now, and switch to 12.3 when 11.x goes EOL.
Not looking for perfection looking for the General available production version, not the developmental/testing/alpha/beta version.
You don't need to be scared. Many popular software in the ports tree is quite stable, their quality is often much better than commercial-only software, and we can call them production quality. OTOH, you'll find many crap as well. Just don't use it.
I just dont understand FreeBSD jargon. I came from Linux. These Open source project release a master version it's what they consider stable. This what am looking for. In a general example Debian has stable - testing - unstable https://www.debian.org/releases/. What is the equal on FreeBSD? I want stable not testing and not unstable.
See above. FreeBSD has current (developer's version), stable (shiny new, but may contain bugs; many use that on desktop machines), and release (for use on production machines). So unless you need a new feature, you want to run a release version on production servers, and run stable in your test lab to detect & fix (or help fixing) bugs & incompatibilities early.
another example Exim is on version 4.94 as stable https://www.exim.org/. Apache is on 2.4.46 as stable release. Are these Quarterly or Latest or Neither.
Remember that the quarterly branch equals the latest branch at the time when it is split off.
Code:
root@t450s:~ # foreach port ( mail/exim www/apache24 )
foreach? echo "[$port]"
foreach? diff /ports/{quarterly,latest}/$port/Makefile
foreach? end
[mail/exim]
2c2
< # $FreeBSD$
---
> # $FreeBSD: head/mail/exim/Makefile 556289 2020-11-25 12:36:05Z fluffy $
[www/apache24]
1c1
< # $FreeBSD$
---
> # $FreeBSD: head/www/apache24/Makefile 544237 2020-08-05 18:29:28Z brnrd $
Ergo: they are identical. If the port's versions would differ, that would be in the Makefile's PORTVERSION. But when Apache releases 2.4.47, it will 1st appear in latest, and 3 month later in quarterly. That's why pinning port revisions is so common: noone of sane mind would call a software stable after only 3 month of testing. A more reasonable approach is to give it at least 3 years. I'm not kidding here.
Well assume you have seperate locations where that code is stored like Stable - Testing - Unstable based on the status of the code from the other project. I dont know as I am new to FreeBSD.
There's no such notion for the ports tree, except the quarterly branch. But, as you already know, that one is identical to latest (i.e., head trunk) every 3 month.
FreeBSD 12.2 the quote Stable branch. I think you all call it RELEASE
Misunderstanding. The head (main trunk) of every major release branch is called stable, and gets cherry-picked feature updates from current (called MFC: merge from current), as well as security fixes. When enough MFCs have accumulated, a new minor release is split off. I.e. currently there is 11-STABLE, 12-STABLE, and 13-STABLE. There is no 11.4-STABLE, nor 12.2-STABLE, but 11.4-RELEASE, 12.2-RELEASE, and soon 13.0-RELEASE. The security & bug fixes are denoted by the so-called patch level appended to the release name, e.g. 12.2-RELEASE-p3. In this process, the cherry-picking of MFCs is done conservatively.
Most confusing is STABLE which seems to be Development.
Yes, that is misleading; it is an historical accident that was never corrected. Again, this is a misunderstanding. Development takes place in current.
 
I think on Linux, though, you get say Ubuntu X, and the ports are "frozen" into that release of X. There are lots of backporters, and they will patch the version of PHP that shipped with X for as long as X is supported. So if X has PHP 5.6, then it will have 5.6 forever, and people will patch PHP 5.6.

If you want PHP 7.x on X, you have to install it yourself.
Yups, and in the end that process isn't stable at all. You're not creating a stable environment, you're merely postponing the inevitable, because all the underlying software does not stop with its own development. Which ironically enough includes the distribution itself as well.

So when you do need to upgrade you're looking at having to skip several major versions in both software and distro, and that can create some seriously dangerous situations because "backwards compatibility" isn't exactly a high priority within most projects, PHP being a shining example here.

In the end you're looking at having to catch up several years of ongoing development with all the risks involved. It's relatively easy to check if your setup works after one major upgrade, but 3 at onces?

Which is why I personally believe that all those "stable" releases are actually far more dangerous than having an ongoing development and update cycle.
 
Like FreeBSD 13 is not "Stable" So I won't use that.
New developments, experimental things, ABI breakages and whatnot is always done in -CURRENT. At some point in time there is some debate about which features and changes to incorporate in the next major version. Once the dust settles a new major -STABLE branch is made and -CURRENT moves on to the next major version and the experimentation, new developments, etc. continue there. The -STABLE label, when looking at FreeBSD's source code refers to the ABI. The ABI is supposed to remain stable, i.e. unchanged, during the time of a major version. -STABLE is considered a development version because there are new features added and removed, it's in essence an early alpha of the next minor release. It's not a place to experiment. From the -STABLE branch -RELEASE versions are branched off. So 12.2-STABLE is now active and from 12.2-STABLE, sometime in September/October, 12.3-RELEASE will be branched off. -RELEASE versions only get bug and security fixes, while -STABLE will move on to 12.3-STABLE and eventually 12.4-RELEASE will be branched off of it. FreeBSD 13.0 was recently branched off as 13.0-STABLE (stable/13) and from there a new 13.0-RELEASE (releng/13.0) was branched off, it will be released soon and you can try the beta releases, there's typically also one or two release candidates for every release. These are for early adopters willing to help out to find and fix issues before the actual release. You can find a schedule here: https://www.freebsd.org/releases/13.0R/schedule/

The version of the OS, any -RELEASE, -STABLE or -CURRENT version has no relation to the ports tree. These are two completely separated entities. All versions on all architectures use the same ports tree, so all supported FreeBSD versions have the same third party applications, with the same versions available to them. This is somewhat strange if you come from a Linux background where the version of the OS is directly related to the version of the software it comes with. On FreeBSD it's perfectly fine to have a 11.4-RELEASE running PHP 8.0 and a 12.2-RELEASE with PHP 7.4 for example, because both 7.4 and 8.0 is available. While the default is set to 7.4, you have all the tools available to set the default to 8.0 if you so desire. The same is true for a lot of other software, like Python (default is now 3.7), Perl (default is 5.32), MySQL is set to 5.7 etc.

another example Exim is on version 4.94 as stable https://www.exim.org/.
Apache is on 2.4.46 as stable release.
Are these Quarterly or Latest or Neither.
Have a look: mail/exim and www/apache24. Freshports conveniently also shows the exact package version that's in the quarterly and latest repositories. Packages are built from ports as I explained earlier, the ports tree is kept under version control and you can browse the various branches too:

HEAD aka latest, Makefile says it's 4.94
2021Q1, Makefile says it's 4.94

You can do the same for Apache24:
 
You don't need to be scared.
Thanks It will take me a minute to answer you all.. I am not scared anymore. I hope I am learning it more and more..
Just don't use it.
Got it like change the tv channel..

FreeBSD has current (developer's version), stable (shiny new, but may contain bugs; many use that on desktop machines), and release (for use on production machines)
In a general example Debian has stable - testing - unstable
Thanks this sums it up. In my brain this is Current = Unstable Stable = Testing Release = Stable
On ports-mgmt/portmaster: don't use it. ShelLser's recommendation is bogus. Period.
I have already read those post. So thanks.
So unless you need a new feature, you want to run a release version on production servers
Thanks I am glad to finally get this in my head. As a FreeBSD noob the I would automatically choose STABLE. (As an aside have they thought of making the Naming more Logical?)
A more reasonable approach is to give it at least 3 years. I'm not kidding here.
Wow. I would settle for 6 months.
There's no such notion for the ports tree, except the quarterly branch. But, as you already know, that one is identical to latest
yep got it thanks.
Yes, that is misleading; it is an historical accident that was never corrected.
Needs to be. I got it now though
dangerous situations because "backwards compatibility" isn't exactly a high priority within most projects
I do agree this is true.
more dangerous than having an ongoing development and update cycle.
I am starting to see that now.
These are for early adopters willing to help out to find and fix issues before the actual release.
Side Note:
How does one become a helper? I can't code. I can test. I can report bugs. Am I allowed to do that? Do I need an account ot approval to log bugs?

The version of the OS, any -RELEASE, -STABLE or -CURRENT version has no relation to the ports tree. These are two completely separated entities.
I think I get it now. Like Mac or Windows can't know if all the software that runs on its OS is any good. Neither can FreeBSD. I dont know why I never thought of this like this with Open Source.
This is somewhat strange if you come from a Linux background where the version of the OS is directly related to the version of the software it comes with.
Yes this is where I was really confused. Rolling release isn't that popular in Linux and neither is Source building only a few are good at it like Gentoo and Arch. This binary stuff is all maintained by the distro. The binarys of all the applications are all compiled and maintained by the Linux team. New versions, backporting and security patches are all maintained a separate repos.
On FreeBSD it's perfectly fine to have a 11.4-RELEASE running PHP 8.0 and a 12.2-RELEASE with PHP 7.4 for example, because both 7.4 and 8.0 is available.
This is actually very cool. In Linux there is cut off point where you can't really use a binary for a old linux version. Openssl is a good example of this you can't upgrade CentOS 6 to the latest version of openssl it is not compatible at all..

I want to thank you all for helping me here. I want you to know I find FreeBSD to be very good. I really like it alot.

In summary

Current = Unstable/Development/alpha Stable = Testing/beta Release = Stable/production

The Ports and packages are "there be Dragons" be warned. Same port for all branches. Quarterly is just older than latest. Might be new version in Latest but that won't be in Quarterly until point in time.

I hope I am at least close..
 
How does one become a helper? I can't code. I can test. I can report bugs. Am I allowed to do that? Do I need an account ot approval to log bugs?
You only need to register, anyone can report bugs and supply or test patches: https://bugs.freebsd.org/bugzilla/

I hope I am at least close..
I think your almost spot on now. It takes a bit of getting used to, things are arranged a little different compared to the average Linux distribution. I like the FreeBSD way of things. I got bitten by the FreeBSD bug more than 20 years ago (somewhere around 3.0) and never looked back.

In Linux there is cut off point where you can't really use a binary for a old linux version.
Versions that are part of the "base" are difficult to upgrade, you'd need to upgrade the OS for that. That said, with regards to OpenSSL, though it's included with the base OS (and thus it's version is "locked") you can build ports using the port version of OpenSSL (security/openssl) or even LibreSSL (security/libressl).
 
As a FreeBSD noob the I would automatically choose STABLE. (As an aside have they thought of making the Naming more Logical?)
The use of STABLE is logical if you think about what they are naming:
The -STABLE label, when looking at FreeBSD's source code refers to the ABI. The ABI is supposed to remain stable, i.e. unchanged, during the time of a major version.
I got corrected myself on these forums, mistakenly linking "stable" to stability of a release, but it's referring to the stability of the programming interface.
 
Q: Now I discovered that some port's versions vary depending on the architecture in the two branches. E.g. Look at the packages supplied for editors/jucipp on FreshPorts: not only the versions differ between architectures, but quarterly > latest for some... (???) Why's that? Does that mean there's a ports(7) tree for every architecture? There's nothing about architecture in the two Makefiles on my machine (I have both quarterly & latest). And why is quarterly > latest in some cases?
 
Why's that?
Some ports have architecture limitations.

Does that mean there's a ports(7) tree for every architecture?
There is only one ports tree, for all versions and all architectures.

There's nothing about architecture in the two Makefiles on my machine (I have both quarterly & latest).
Then the lack of a package is likely due to build failures. Sometimes a port builds fine on AMD64 but fails to build on ARM for example. Tier 2 and 3 architectures don't get the same attention as tier 1 does.
The ports infrastructure should include basic support for Tier 2 architectures sufficient to support building ports and packages. This includes support for basic packages such as ports-mgmt/pkg, but there is no guarantee that arbitrary ports will be buildable or functional.

If you're referring to aarch64 packages, if I recall correctly the hardware that built those packages is broken. May have been fixed in the mean time, then broke again, I'm not sure.
 
Just my 2¢ about that to the OP:

FreeBSD (the system, also called "base") DOES aim for "production quality" with its RELEASE versions, and does so pretty successfully; yes, this can be compared to Debian's "stable".

But, for me, one of the biggest advantages of FreeBSD is exactly that ports are completely separate. Trying to ensure "production quality" for tons of 3rd party software as a distributor is a race you will always lose anyways ... see Debian "stable" here as a bad example. The only thing that makes sense here is the "rolling release" scheme: continuously update the ports, make sure they work on any supported FreeBSD version, do snapshots for those who don't want to continuously update and make sure you merge important security fixes into these snapshots -- that's what FreeBSD's ports are doing. For ports that HAVE a "long term support" release upstream, just offer two ports.

In the Linux world, at least as far as I know, you have to decide whether you want a distribution like Debian "stable" including ages-old application software, or a complete "rolling release" system. With FreeBSD, have a rock stable base system and still enjoy the latest and greatest apps running on it.
 
In the Linux world, at least as far as I know, you have to decide whether you want a distribution like Debian "stable" including ages-old application software, or a complete "rolling release" system. With FreeBSD, have a rock stable base system and still enjoy the latest and greatest apps running on it.
Definitely, and this makes FreeBSD much better suited for desktop computing than Linux, in my opinion. Desktop users want up to date applications on a stable, reliable base, and most Linux distributions fail at that by either providing outdated software or updating every system component to the latest version at the risk of breaking the system anytime. No wonder Linux desktops are still unpopular except among developers (who are happy to use the latest version of everything and are able to troubleshoot problems), despite many clear advantages against Windows and lots of money having been invested in that market in the past. Companies once working hard to provide the best Linux desktop experience have either got bankrupt (Mandrake/Mandriva) or refocussed on other markets (SUSE, RedHat and Canonical).

Nowadays you have various workarounds available, each having its own problems. Flatpak and Snap bring unnecessary complexity and bloat (like on Windows). AppImage is a cleaner design but means you have to update every application separately (like on MacOS before the app store times). Both systems mean wasted disk space because of all dependencies included in each program. The least problematic system in my opinion is the use of extra repositories, like Debian backports (not a lot of software available) or openSUSE "experimental" repositories (much more), but this is still less practical to manage than FreeBSD, which allows you to install a fairly up to date version of any ported software with a single pkg install.
 
bsduck, it's an interesting thought that Windows actually provides a similar thing. Of course at the cost that the user has to "manage" all 3rd party software himself. So, I would conclude FreeBSD (or any BSD working with a similar model with packages built from "rolling release" ports) is still like the best of all worlds, at least for my usecase ;)

edit: on a second thought: mobile systems have you covered in a somewhat similar way. My Android device will update "apps" automatically and just take what's coming from upstream, while the base system is handled in release cycles. Of course, this suffers different problems as many vendors don't deliver the quality (especially timely security fixes) for their base systems as you would expect, but in principle, it's somewhat similar ;)
 
Back
Top