What does "stable" really mean in relation to code?

Question

I often see or hear people describe something as "stable" in relation to code.

Am I right in thinking that a "stable" class library is one in which the functions have been well tested, used in the real world and not been found to contain any bugs? Or at least any purpose critical bugs.

How, then, does this relate to large pieces of software like operating systems? I often see a download described as "stable", which is usually a few versions behind the latest releases. Exactly when does a piece of software become stable? Are there any criteria for determining this?

Answer 1

Its not being changed a lot. Usually that means its good, working and has no bugs.

A "stable" release in terms of libraries is typically a "recommended" release where a more "bleeding-edge" release is also available. In such a scenario it is wise to use the stable release for production code.

Exactly when does a piece of software become stable? Are there any criteria for determining this?

This is a very subjective piece of criteria. Typically its a result of the release having undergone rigourous QA and/or having been released without any serious issues being reported. However the usage of the term depends on the team's measurement so one man's "stable" might not be anothers.

Answer 2

There may be a more formal definition but in my experience it means a release that is tested and found to be usable and meets requirements; maybe not free from bugs but no major bugs. Most users will be able to use it without experiencing any major issues (e.g. data loss, crashes).

An unstable release will either have many bugs (or a few significant bugs), or simply not be tested.

Answer 3

The definition is technically based on whatever that producer or labeller of code defines. One company/project definition doesnt have to match another.

But it usually has to do with mileage. At some point you declare that you are stopping the addition of features and heading for release. Then during your testing at some point the bug report rate takes a turn downward, you then promote that product to more people alpha, beta, release candidate, etc. More people more testers, more potential bugs. over time that product matures, the user base increases and the bug rate eventually slows down. When it reaches a point where you consider it to have the features you wanted, it works, and the bug rate is low enough you declare it to be stable and if not already move more resources off of that version/product and focus on the next one.

The metric will generally have to do with bug rates, how many bugs, how much time you spend on customer/user support. When the users stop bugging you about the product it is because: 1) they stopped using it 2) they keep using it but it has matured to the point where it is stable enough for them to use without complaining.