Heptapod 0.20 pre-release
Posted on Mon 22 February 2021 in announcements by Georges Racinet
Heptapod 0.20.0rc1 was released today, featuring GitLab 13.9 and aiming for a final version on March 2nd. Many thanks to all our contributors, of any kind. Please give it a try, and tell us about it!
The release candidate was installed shortly afterwards on foss.heptapod.net.
Heptapod 0.20.0rc1 can be installed as a Docker image and from source (don't miss the new Workhorse instructions).
The full changelog is available as usual alongside the sources.
Short term release schedule and installations
For the first time, we're releasing the Heptapod release candidate the same day that upstream Gitlab release their x.y.0 version. An immediate benefit of this for our users is that the previous Heptapod 0.19 version will stay supported a few weeks instead of a few days.
The RC phase will end on March 2nd, with the final release of Heptapod 0.20.0 and immediate installation on the flagship platforms: foss.heptapod.net and heptapod.host. The former will run the release candidate until then.
GitLab 13.7 and thus Heptapod 0.19 will their end of life on March 22nd.
Heptapod Workhorse sources do not live in a separate repository anymore, but in the workhorse/ subdirectory of the main repository.
This has no impact for users of the Docker image or the Omnibus packages.
Upstream has been preparing this for months, with a gradual transition plan that is now nearly complete. Heptapod having fewer build and deployment options, we wanted to spare us such an effort. This was actually the primary motivation to jump directly on GitLab 13.9, a version fully ready for the bundled Workhorse, thus skipping 13.8.
The install documentation has been updated to reflect the change, the short summary for new installations being that applying upstream GitLab procedure (Rake task) just works.
For more details and pointers to upstream information, see our tracking issue, heptapod#402.
Docker image and Omnibus package
Our Docker image makes a big leap, being now based on Ubuntu 20.04 instead of Ubuntu 16.04. Most users shouldn't notice any difference.
This also follows an upstream GitLab move), due to the EOL of Ubuntu 16.04 in April 2021.
We are still building only the variant for the Docker image. Nothing changed for Heptapod 0.19 Omnibus builds. To summarize, here are the Omnibus packages that we are currently producing:
- Heptapod 0.19: Ubuntu 16.04 (xenial)
- Heptapod 0.20: Ubuntu 20.04 (focal)
These packages aren't widely distributed yet. Also, nothing prevents us to build for other targets (Debian stable would be an easy one). Don't hesitate to contact us if you are interested.
Next development highlights
Heptapod 0.19 will keep on receiving bugfixes and low risk features until March 22nd.
The effort announced with Heptapod 0.19 is still ongoing, partly because we moved faster towards Heptapod 0.20 than expected a month ago.
Mercurial native mode
All newly created Mercurial projects on foss.heptapod.net are native. Currently, that only means that their commit hashes are native, but that makes the most difference for users. More details are available on the HGitaly1 milestone.
Progress towards the HGitaly2 milestone:
- The processing of new changesets for messaging to the Rails application is now ready to work without a Git repository.
- Experiments to expose changeset content through HGitaly are roughly halfway through. These are manifests and files in Mercurial terminology, trees and blobs in Git(aly) terminology. This is where the most risk lies, due to the Git-centric identifiers used by the Gitaly protocol
- Good progress has been made also in the exposition of diffs, for which the protocol translates more directly in Mercurial terms than for trees and blobs
- Work has started on migration tasks and other transition helpers, see the heptapod#420 and heptapod#421 tracking issues.
We're delighted to give our users more time to upgrade before the end of life of the current stable series, Heptapod 0.19.
We would be very happy to release the next version so shortly after GitLab 13.10, but this would be but one goal among many. We'll certainly try if we have the resources.
Thank you for reading so far, and again, many thanks to all the people that contributed to this release, be it by funding, submitting code, documentation, or simply user feedback.