#pragma section-numbers 2
<<Include(A:dev)>>

= Developer information about Extensions =

Core developer related information about the extensions that lives in the Mercurial repository.

<<TableOfContents>>

== Feature life cycle ==

A common life cycle for a large new feature in the Mercurial world is:

 1. created as a third party extension,
 2. moved into the core repository as an experimental extensions,
 3. loose its experimental status and become an officially bundled extensions,
 4. the feature eventually makes it into core (often)

Until it becomes an officially bundled extensions, we do not grantee backward compatibility (however, some third party extensions may). After that our CompatibilityRules applies.

There is a couple of spot where we can afford breaking the compatibility:

 * When taking the extension into the core repository as experimental (under a different name),
 * When moving the feature into core (under a different user interface),

== Extensions versus Core Code ==

<!> The following list is the result of discussion at the [[3.8sprint]]. It has no official or absolute value.

There are multiple common reasons for a feature to live as an extension:

 * the feature/code is still too young for us to be confident
 * the feature/code is currently too buggy to get wider exposure
 * the feature is too niche, the small set of user who actually needs it can bare with the extra step of enabling it (the extension will probably never makes it to core)
 * using the feature on repository have global and irreversible effects (eg: subrepo, largefile)
 * the feature is a dangerous footgun and does not fit in safety-focused feature set of core Mercurial
 * the current user interface of the feature is not satisfactory and we would like a better story before moving it into core
 * the feature requires dependencies to be installed (we are unsure about this as a blocking criteria)
 * last but not least, if the extension have been judged suitable for core but nobody did the work to actually port the code, it still lives as an extension

== Current list of extensions ==

(deprecated and experimental extension have been excluded)

<!> This table have been annotated with the result of the discussion at [[3.8sprint]].
This is just a gathering of the brain storming that happened there and has no official or absolute value.

|| '''Extension''' || '''Attributes''' || '''Candidate for core''' || '''Notes''' ||
|| acl       ||            ||                    || not discussed ||
|| blackbox  || too young?, too buggy? ||        ||               ||
|| bugzilla  || too niche  || {X} || ||
|| censor    || too young and too niche || {X} || ||
|| churn     || || || not discussed ||
|| clonebundles || too niche || || Server only extension. If you are a server administrator you can probably bear with an extension.||
|| color || || (./) || ready to get into core (disabled by default) ||
|| convert || too niche, introduce dependencies || ||  ||
|| eol || too nice, too buggy, footgun, irreversible? || {X} || Last resort feature ||
|| extdiff || UI need reconsideration || (./) || Having this in core as a `--tool` option for `diff` would be nice ||
|| factotum || too niche || {X} || ||
|| gpg || too niche, UI need reconsideration || {X} || will eventually be deprecated by CommitCustodyConcept ||
|| hgcia || too niche || {X} || associated service is dead, should we remove the extension? ||
|| hgk || introduce a dependency || (./) || It would be nice to have a `hg view` command in code were various UI could plug in (tk, qt (TortoiseHG(), HgWeb, …) ||
|| highlight || introduce a dependency || (./) || Should automatically be on if Pygments is present? ||
|| histedit || footgun, reconsider UI?|| || ||
|| keyword || too buggy, too niche, footgun, somewhat irreversible? || {X} || last resort feature ||
|| largefiles || too buggy, irreversible, reconsider UI || {X} || There have been discussion at the [[3.8Sprint]] to replace it with something better ||
|| mq || || {X} || not really discussed at this is planned to be obsoleted by evolution ||
|| notify || too niche || {X} || ||
|| pager || too buggy, reconsider UI || (./) || Augie have a plan to fix the behavior and get this into core (disabled by default) ||
|| patchbomb || too niche ? || (./) || ||
|| purge || footgun, reconsider UI || (./) || Durham had idea about how to make it less a footgun ||
|| rebase || reconsider UI || {X} || Matt does not like the UI, we would be happy to learn more. (and the rebase-set selection options (`--base`, `--source`, `--rev`) are currently confusing)||
|| relink || too niche || (./) || could maybe make it in as a debugcommand ? ||
|| schemes || reconsider UI ?|| (./)  || ||
|| share || too buggy, reconsider UI || || ||
|| shelve || too young, too buggy, reconsider UI || || ||
|| strip || footgun || {X} || core use-case should eventually be superseded by Evolution ||
|| win32mbcs || too niche || {X} || ||
|| zeroconf || too niche || {X} || ||

----
CategoryDeveloper