Topic on Template talk:Extension

The status ladder seems slightly odd. The one I'm used to follow is the w:Debian style Experimental, Unstable, Testing, Stable, Oldstable, and Oldoldstable. The ladder this template use is unstable, experimental, beta, stable, unmaintained, archive, and unknown. Some of the states are clearly not similar, but the initial ones can give rise to quite worrisome misunderstandings. An extension flagged as unstable in Debian is way better than experimental, but unstable in this scheme is simply broken.

The term beta is also troublesome, as it relates to the release cycle. Typically a release cycle consists of alpha, beta, and release candidate. The status of the extension sets the limit for the final release quality, but it is not part of the release cycle. I believe the term beta should be removed. [Note that IBM use the alpha, beta, and release candidate for the w:Software release life cycle.]

Either the status ladder must be marked as non-standard, or the status ladder must follow an established standard. If it follows an established standard, then I would vote for using Debians status ladder.

I don't think debian style ladder is useful here, since that applies to versions of a release, and not the current status of an extension

Versions of a (pre)release is (or should be) alpha, beta, and release candidate, while status is (or should be) Experimental, Unstable, Testing, and Stable. You can have several releases without ever changing the status.

Still what is really bad with our status ladder is our use of unstable as broken. That creates a lot of confusion.

Ok, so let's not give them status name for now and just collect all the possible or interesting status:

• Extensions that are maintained and kept up-to-date with the release lifecycle of MediaWiki, with no expected breaking changes.
• Extensions with very active development that expect breaking changes as new features are being added.
• Unmaintained extensions that are kept up-to-date by volunteers but there's no official maintainer. It can take months to fix bugs that make the extension unusable when a new MediaWiki version is released.
• Unmaintained extensions that worked on previous versions of MediaWiki but are broken on recent versions of MediaWiki and there are no volunteers that provide patches for them to work (abandoned).

Those are the 4 status that I think would be useful to know about an extension.

I would say the order is

1. (experimental) Extensions with very active development that expect breaking changes as new features are being added. (start-of-life)
2. (unstable) Extensions that are out of the most active phase, is usable, but still without a live testing environment. An extension in unstable could have critical issues.
3. (testing) Extensions that are out of the most active phase, and is usable, with a live testing environment. An extension in testing should not have critical issues. (The template should link to the testing environment.)
4. (stable) Extensions that are maintained and kept up-to-date with the release lifecycle of MediaWiki, with no expected breaking changes.
5. (oldstable) Unmaintained extensions that are kept up-to-date by volunteers but there's no official maintainer. It can take months to fix bugs that make the extension unusable when a new MediaWiki version is released.
6. (abandoned) Unmaintained extensions that worked on previous versions of MediaWiki but are broken on recent versions of MediaWiki and there are no volunteers that provide patches for them to work. (end-of-life)
7. (archived) After a one year grace period as abandoned the extension should be archived.

We should probably have some kind of badges on the extension page, like there are at Github, to show which extensions passes unit test, and also the number of open issues.

I don't see how unstable and testing fits with extensions. What do you expect as a "testing environment"? Extensions in such a state can be in a production environment (live wikis not meant to be a testing wiki), and those names have no meaning about usability or critical issues, which is misleading. Unstable and testing shouldn't be considered IMHO.

A live testing environment is not the same as a production environment. You might set up a production environment with horribly broken software, nothing stops you. Having a testing environment imply that you have (integration) tests and can prove the extension work properly. That is you don't just include the extension and verify it shows up in Special:Version, you actually run real tests. That means most extensions for Mediawiki will only reach unstable, – not testing, not stable, and not oldstable. At some point such extensions go straight to abandoned.

An other way to explain it is a ladder of

1. (experimental) Still being developed as one or more spikes and optionally stabilize, that is largely missing tests
2. (unstable) Is predominantly developed as test and development cycles, that is it has at least unit tests
3. (testing) Has public (live or for download) integration and unit tests with good coverage
4. (stable) Has some form of release management

If you can't prove it to be working, then you can't claim it to be stable.

(Or as a co-worker told me once: Is a completely broken thing stable in its brokedness? It does not implement its intended functionality.)

I'm against including the existence of coverage test to claim an extension is any of those statuses. A new property in the extension infobox to tell if the extensions has tests could be good, but not for the status of the extension, because it doesn't mean much.

And then we're back to why I believe the current status ladder is wrong; it has no real meaning, it is simply (made up) names.

IBMs old status ladder

1. (pre-alpha) activities performed during the software project before formal testing (Wikibase while being modelled was here.)
2. (alpha) first phase to begin software testing using white-box techniques
3. (beta) the software is feature complete but likely to contain a number of known or unknown bugs (perpetual betas live here. This is unstable.)
4. (release candidate) software with potential to be a final product, unless significant bugs emerge
5. (stable) software released for general use

That's more meaningful. Still, "release candidate" probably won't be used

I don't think the debian model fits with extensions very well. Status should more be taken a reflection of the quality of the current master release of the software. Some software might start at the top of the "ladder", others might stay at the bottom with no intention of moving up.

I agree though that its mostly meaningless, as its self-assesed, with no shared common understanding of the definition of the labels