Note:

This page is primarily intended for developers of Mercurial.

Developer information about Extensions

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

1. 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:

2. 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:

3. 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

ExtensionsDevel (last edited 2016-03-30 01:12:48 by rcl)