Heptapod 0.26.0rc1 released, 1.0 now in sight
The release today of Heptapod 0.26.0rc1 brings in ground work for the fully native Mercurial support and the new "Mercurial Publisher" role. Read below for more details about these.
As we announced earlier, this new series does not include an upstream GitLab version change. Instead we boosted Python to 3.9 and Mercurial to 5.9. Don't miss the related changes in the procedure to install from source.
The release candidate was installed on October 26th on foss.heptapod.net. The final version will be installed simultaneously on foss.heptapod.net and heptapod.host.
Heptapod 0.26.0rc1 can be installed as a Docker image and from source.
The full changelog is available as usual alongside the sources.
Many thanks to all the people involved to make this happen!
The new "Mercurial Publisher" role
This release introduces a new "Mercurial Publisher" access level, that can be selected in membership pages for Groups and Mercurial Projects. It sits between Developer and Maintainer
As the name should suggest, the effect is to allow pushing public changesets or changesets that will be automatically published. With the default workflow of Heptapod, this boils down to changesets without topics.
In Heptapod 0.26.0 (final), the Mercurial Publisher role can be selected in protected branches settings. This was not true of in release candidates.
See also the online documentation.
Preparations to drop the conversion to Git
As explained in The road to fully native Mercurial in Heptapod, Mercurial repository content is still converted to this day to an auxiliary Git repository, even for "fully native" Mercurial projects.
Heptapod 0.26 does not change that, but it contains all the internal infrastucture changes to do so, with the introduction of a single switch to flip, currently more akin to a circuit board fuse to blow than to the neat red one that is shining on your power conditioner. Yet this makes for a fair amount of changes in itself (heptapod!289, py-heptapod!65), that we will be happy to stabilize ahead of time.
Another benefit of this effort is that we now have a clear picture of what is still missing in HGitaly, and it's not much:
- support for programming languages detection. For that purpose, GitLab uses the very Git centric GitHub Linguist Ruby library. We will need a Mercurial extension providing the same functionality. There's a good chance we'll create it ourselves, and if that happens, it will be released separately for the benefit of the broader community.
- support for checked-in attributes. In truth, we can ignore it, as Mercurial projects don't recognize any such things and it is unlikely that many have a .gitattributes, to rely on the default GitLab support of them.
- a few repository content searching methods that are not widely used within the GitLab code base yet.
Closing this gap will probably have us celebrate and label the corresponding version as Heptapod 1.0.
Roadmap towards Heptapod 1.0
With GitLab 14.2 being scheduled for end of life on November 22nd, we will have to switch back our focus to catching up with upstream.
It is therefore unlikely that Heptapod 0.27 can provide the option to unplug the Git repository, and even less to make it standard but Heptapod 0.28 probably will.
All in all, we can now expect Heptapod 1.0 to happen around the end of this year, perhaps in lieu of 0.29 or 0.30.
In conlusion
Thank you for your attention, and don't hesitate to give us feedback about the subjects mentioned above.