Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2016-03-30 00:44:58 →
Size: 5125
Editor: rcl
Comment: fix bullet points notation
← Revision 4 as of 2016-03-30 00:45:59 → ⇥
Size: 5127
Editor: rcl
Comment: fix another set of bullet points
Deletions are marked like this. Additions are marked like this.
Line 23: Line 23:
* 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),		  * 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),

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.

Contents

  1. Feature life cycle
  2. Extensions versus Core Code
  3. Current list of extensions

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:

  • 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),

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:

  • 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

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

This is a server only extension, if you are a server administrator you can probably bare 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}

This is a 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 pigment 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 a better something else

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)