/!\ This page is primarily intended for Mercurial's developers.

Experimental Extensions

Plan to define a way to have some experimental extensions part of the core Mercurial repository.

Such extensions would be marked as experimental and BC (backward compatibility) is not guaranteed (to the point we could just remove them entirely).

1. Rational

Having extensions in the main Mercurial repository have some advantage:

2. Criteria for acceptance

The general philosophy of accepting experimental extension is:

This translate into the following more concrete criteria:

3. Current Experimental Extensions

3.1. AutoMV

3.2. FSMonitor

3.3. JournalExtension

4. Current Candidate extensions

4.1. LogToProcess

5. Possible Drawback

5.1. Constraint on Code Quality

Extensions are used to make dirty prototypical extensions were code quality is not up our standard. And then to clean up architecture and code when they move into core (eg: that for phase, obsmarkers, etc).

Being able to freely experiment is important to converge to a good solution quickly.

Experimental code often have narrower target in term of OS and Python version. The would be an issue for the tests.

Finally moving the load of update crappy code to better API when we rework core from the author of the crappy code to the author of the factory cleanup is probably a loss.

5.2. Constraint on review process

Our patch flow is still not great, review process and latency can significantly slow down development. We need a solution to ensure maximum velocity for experiments.

5.3. Constraint on release cycle

This is the main issue here, 3 month latency is far too long for experiment. The goal of experimental extensions are to ship potential new feature to the user quickly. Version are usually made the same week an important feature is added. Multiple version to adjust the behavior might happen in the same month. Experimental extensions are likely to have show-stopper bugs that prevent user to user Mercurial until it is fixed.

5.4. Constraint on release target

In addition, the target user base does not necessary run the latest mercurial. as a result extensions are often compatible with multiple older version (eg: Evolve is compatible down to 3.4 for this purposes)

This would be hard to test and implement once trapped in Mercurial main repository.

6. Possible Solutions

6.1. Code Quality

We could have lower code quality norm for the experimental extensions. This does not solve the tests issue, but we could throw enough condition to skip them for anything unsupported (even skipping check-code?).

We seem to have some consensus on that.

6.2. Constraint on review process

We could have direct push for the experimental extensions.

We do not seem to have a consensus here.

6.3. Constraint on release cycle

This is a hard one. Could we have some extra package containing stable + latest extension (require some branch witchcraft).

6.4. Constraint on release target

This is a harder one. Maybe this requirement need to be relaxed (with then, more filtering on what extensions are eligible).

We can probably also work around that with bigger branches witchcraft in a dedicated repository.

CategoryDeveloper CategoryNewFeatures

ExperimentalExtensionsPlan (last edited 2016-06-29 18:00:08 by MartijnPieters)