As of this writing, Heptapod is climbing the final steps towards version 1.0, the first fully supported stable version according to most conventions.
This document presents how the development is organized and sheds light on the expected contents of future versions up to Heptapod 1.0.
Goals and Priorities
to help us with prioritization, vote with the thumb buttons on Heptapod issues, and don't hesitate to create new issues.
In Heptapod development, we're pursuing different goals on which we work in parallel. These can be roughly categorized as follows:
- Catch up on currently supported GitLab versions. More generally, remove dependencies onto obsolete software.
- Reach full native Mercurial support in the web application (interaction with Mercurial clients has always been native).
- Enable standard GitLab features. For instance, wikis were not supported before Heptapod 0.13
- 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.
- 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.
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.
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.
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.
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).
Reached at the end of May 2020 with the release of Heptapod 0.13.0.
This version brought in support for wikis and important internal changes to prepare for subsequent versions.
It can run indifferently on Python 2 or Python 3 (Docker images for both are available).
This version was originally meant to appear in early May 2020, but in the meanwhile, our last dependency got ported to Python 3, opening the road for Heptapod itself. We decided it would worth the delay to release a Python 3 version earlier because that increases the timespan of testing, and it makes a separation of concerns with Heptapod 0.14.
Reached in early April 2020 with the release of Heptapod 0.12.0
The main goal was to jump from the really old GitLab 10.5 to GitLab 12, the current major version. This didn't bring us to a currently supported minor version: we stopped at 12.2 whereas the oldest supported upstream would have been 12.8 at the time.
Because we crossed two GitLab major version changes, we had to prepare intermediate versions dedicated to data migrations. That's why there's no real Heptapod version between 0.8 and 0.12
Reached mid January 2020 with the release of Heptapod 0.8.0 this was the first version to be installable from source.
It also brought SSH support to the table.