#RFC: A-Badge for extensions ##Purpose * There are plenty of extensions in TER, often with a similar feature set (by reading the description) * Quality may differ much between similar extensions * Choosing the right extension may be done by looking at the download counter and the last update or frequency of updates but it does not say about its quality nor its perennity (e.g., it's often said that EXT:news should now be used in favour of EXT:tt\_news) * Updating an extension should be worryless (is something breaking, should I fear upgrading from v. 1.2 to 1.3 or from v. 1.2.4 to 1.2.7?) ##Idea * "Marking" extensions as "the way to go" from a central team (e.g., ECT) is not feasible (this was the long awaited concept of "A-Class Extensions") * We want to introduce a community-driven "A-Badge" for well-maintained extensions (sticking to common rules) * Author should be able to self mark its extension as respecting the rules below * Community users should be able to report if an extension is not sticking to the rules * Such extensions should be better ranking in TER **and** in EM (position in search results, relevance, ...) * => This will need changes on TER+EM * => We should first agree on the rules * It's not only about code-quality (CGL, ...) but user-centric point of view ("its use in a website" and its "stability" over time) but code-quality (as measured on metrics.typo3.org) may be taken into account for ranking purpose ##Rules * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (\url{http://tools.ietf.org/html/rfc2119)}. ###Stability * The extension MUST be marked as "stable" in TER * Same rules as for TYPO3 CMS Core: * No new features or breaking changes in patch release versions, meaning extension versioning scheme follows same rules as TYPO3 Core and \url{http://semver.org/} * Security releases must not contain new features (=> patch release scheme) which is part of the Extension Security Policy (\url{http://typo3.org/teams/security/extension-security-policy/)} * Deprecation over two minor versions (note from Ernesto: you mean two "minor version", right? i.e. 1.4 .. 1.6) for breaking changes using TYPO3's deprecation log * In case of breaking changes between minor versions, extension should come with an upgrade wizard or at least detailed instructions on how to upgrade ###Feedback * A publicly accessible bug tracker MUST be used to let users report bugs and post suggestions ###Auditability * Extension MUST either (I would suggest, that using a VCS is a MUST for A-Class-Extensions ~hh) * Be developed on a public versioning system (and thus give access to a log of changes ideally conforming to Core format) * Or provide a detailed changelog with each release * Extensions using a public versioning system (e.g., Forge, GitHub, ...) SHOULD use tags (or similar) related to TER releases ###Long-Term Support * As of the first upload to TER, extension MUST remain compatible with at least the oldest still active version of TYPO3 ever supported * Either as separate branches (e.g., 4.x / 6.x) * Or as a single compatible version * => this means that an extension may be compatible only with 6.x from start, but should not drop (e.g.) 4.5 support as long as 4.5 is "officially supported" * PHP version * Lower version requirements SHOULD be kept over minor versions with the exception that it may be raised if a newer version is considered to be available in common operating systems in their corresponding "stable" branch (note from Ernesto... something is missing in this sentence. Is considered.. what?) * As new minor versions of TYPO3 CMS are released, compatibility SHOULD be kept in sync without a delay of more than one version (e.g. compatibility with 6.1 as soon as 6.2 reaches feature freeze milestone) ###Documentation * The extension MUST provide a documentation on what it does, how to use it and/or how to manage it: * It SHOULD be written in reStructuredText (README.rst or Sphinx project) instead of OpenOffice document (manual.sxw) * Structured wiki pages (or dedicated website) are of course fine as well ###Benefits for the developer (IDEAS!) * Boosting in the results on typo3.org and extension manager's list * Highlighted result entry * Dedicated page on typo3.org * Access to a fixed money budget of T3A * Translation on Pootle (translation.typo3.org) since we have no rule currently and basically (now) accept every request even if makes no high sense