I’ve come to learn that when someone refers to software as ‘stable’, there is more than one quite different thing they might mean.
A stable software release
A stable software release is so named because it is unchanging. Its behaviour, functionality, specification or API is considered ‘final’ for that version. Apart from security patches and bug fixes, the software will not change for as long as that version of the software is supported, usually from 1 to many years.
Software that is intended for the public to use is usually “stable”. It is released, and following the release no new features are added apart from the odd bug fix. To get new functionality users eventually need to upgrade to the next version. Any problems with the software (unless they can easily be fixed with a bug fix update) are “known” problems, and the software vendor does not need to keep track of more than one variantion of these problems for any given version.
Examples of releases that are the opposite of stable include development snapshots, beta releases, and rolling releases. A characteristic of all three of these is that they are in a frequent state of change; even their functionality and feature list can change from week to week, or day to day. You cannot depend on them to behave the same way from one week to the next.
Some people like that with non-stable releases such as development snapshots, beta releases or rolling releases, they are always getting the latest features as soon as they are written into the software. In many cases, these releases also fix deficiencies or bugs that would otherwise remain stagnant in the stable release. However, with no stability in the feature list or functionality, this affects the ability for documentation, other software that interfaces with the software, plugins, and more to function: a change in the software can mean these become out of date or fail to work anymore. When you have software which needs to work well with a lot of other software, having a stable release reduces the frequency with which changes in the software will break compatibility with the other software relying on it.
Another meaning of stable
Another meaning of stable exists in common use, where people take it to mean “working reliably” or “solid”. That is, people refer to software that runs consistently without crashing as stable. You can see why they may use the word in this way: in real life, when something can be described as stable, it won’t fall over. If a chair is stable enough, you can sit in it and it won’t topple or collapse.
However, confusion arises when people use this form of the word stable to refer to software that isn’t stable in the earlier sense. For example, it’s why you see comments like “I’ve been using the beta version since February and it is very stable” or “the newer version is more stable”. The point that these comments make is not that the software is final and unchanging, as in a stable software release, but more that the software is stable like a chair might be stable. It seems reliable, and the user hasn’t experience any major problems.
This kind of stability won’t help developers extending the software with other software, or writing plugins or customisations for the software, since the fact that at any given time the software is running well does not make up for the fact that the software is subject to frequent changes.
Commenters or reviewers who describe beta or rolling releases of software as stable, might want to try describing them as “solid” or “reliable” instead, to save confusion with a stable release which is an unchanging release. Or, the fact that the same term is understood in two different and sometimes conflicting ways may indicate that the term is not an ideal one in the first place. It does, however, seem firmly entrenched in the software development world, where the meaning of a stable release is well known.