Roadmap

Goals and Priorities

In Heptapod development, we're pursuing different goals on which we work in parallel. These can be roughly categorized as follows:

1. Catch up on currently supported GitLab versions. More generally, remove dependencies onto obsolete software.
2. Reach full native Mercurial support in the web application (interaction with Mercurial clients has always been native).
3. Enable standard GitLab features. For instance, wikis were not supported before Heptapod 0.13
4. Make the Bitbucket import as complete as possible. This latter category is short lived, as there won't be any repository to import from Bitbucket after July 1st, 2020, but it may find new incarnations after that.
5. Support our early adopters, fixing the issues they encounter and generally catering to their needs.

The first two goals are basically the requisites for the fully supported stable version 1.0 that we want to reach as soon as possible.

We give the first two goals a loose priority over the others: we tend to postpone fixes and features that depend on improvements related to goals 1 and 2, or would have to be entirely redone later down the road. Of course that depends on the impact on our current user base and is decided on a per-case basis.

Milestones

We use the standard Milestones feature of our Heptapod development instance to group issues by versions and give an idea of the time frame. Check them out if you wish to go into more detail than is available on the present page.

At least until Heptapod 1.0 and the end of Mercurial on Bitbucket, the milestones are only indicative: We're routinely rescheduling issues and sometimes update major goals according to external constraints and new opportunities.

Structure of a pre 1.0 development cycle

Here is how it generally happens.

Major changes in dependencies and features involving serious refactorings appear in the 0.x.0 version (normally since the first release candidate), and won't change in subsequent 0.x.y releases.

For example, Heptapod 0.13.0 bumps GitLab version from 12.2 to 12.3 and brings in support for wikis.

During the lifetime of a 0.x version, we turn to features that don't break compatibility and don't involve major refactorings. For example, the implementation of commits squashing appeared in Heptapod 0.12.2.

Some intermediate releases may introduce "technology previews", optional changes that should become standard in the next 0.x version. This gives us a chance to validate them in advance. For example, Heptapod Workhorse appeared as a technology preview for source installations in Heptapod 0.12.1 and becomes required in Heptapod 0.13.

Heptapod 0.14

See also the Heptapod 0.14 milestone on foss.heptapod.net.

This version will finish catching up on upstream GitLab, being based at the minimum on GitLab 12.10.11.

GitLab 12.10 is not only currently supported, it is also the last of the GitLab 12 series, which means that Heptapod users will experience a normal data migration when we'll move further to GitLab 13.

Heptapod 0.14 was originally meant to also be the first one with native Mercurial support in the web application, but we've decided that being based on a currently supported GitLab version was worth a release in iself, and we split it in two.

The native Mercurial support is now scheduled to be released with Heptapod 0.15, perhaps after an appearance as a technology preview in the 0.14 cycle.

Heptapod 0.15

See also the Heptapod 0.15 milestone on foss.heptapod.net.

This version is meant to be the first one with native Mercurial support in the web application. Except for wikis, we won't be using an auxiliary Git repository to expose content to the web application. This will make the user experience much more consistent and will remove major performance and scalability bottlenecks.

Heptapod 1.0

See also the Heptapod 1.0 milestone on foss.heptapod.net.

As the number suggests, this would be the first version to be deemed fully supported and stable.

We'd be really happy to reach it by the end of June.

As already stated, it has to be based on a supported GitLab version and feature fully native Mercurial support.

Some speculative secondary goals:

• Dual VCS: support for Git!
• Omnibus deployments (actually a technical requisite for many improvements, including dual VCS support.
• Heptapod Development Kit: adapting the GitLab Development Kit to Heptapod (could become a priority before that depending on the needs of incoming contributors).

Past milestones