Heptapod 0.25.0 released, featuring GitLab 14.2
We're glad to announce the release of Heptapod 0.25.0, based on GitLab 14.2 and making Mercurial native projects the default for creations.
As previously explained, to upgrade an existing instance to 0.25, one needs to start from a Heptapod 0.24 instance whose background migrations have already fully run.
Read below for more details about this release and have a glimpse of the close future.
Heptapod 0.25.0 can be installed as a Docker image and from source.
The full changelog is available as usual alongside the sources.
Thanks alot to the people that have contributed to this version.
Prime time for Mercurial native projects
Let's be really clear: this is only about new projects. Existing projects are totally unaffected by the change explained in this section.
Heptapod can host two different types of Mercurial projects: the "native" projects already feel as though no conversion to Git was happening behind the scenes and will be carried over with no data migration to the day we finally stop converting to Git as a technical crutch. On the other hand, the non-native projects do rely on the inner Git conversion for exposition to the web application, resulting in various inconsistencies in the user experience (see heptapod#6 for some of them).
Because the native Mercurial projects are relatively new, they were until today's release stricly opt-in: instance Administrators had to allow them explicitely in Application Settings. Similarly, the Group settings for VCS type was by default set to non-native Mercurial.
With Heptapod 0.25.0, the native Mercurial VCS type takes the place of the non-native one for Project creation both in the Application Settings and in all Group settings. At this point we felt we had enough testing of native projects, and that creating further non-native ones had become a disservice to users.
Instance Administrators and Group Maintainers may revert that change, although we'd advise not to do it except a serious problem has been detected. In that latter case, we'd like to hear about it, naturally.
We won't change these settings again until we drop the support for non-native projects, which lies way further in the future. What we may do, though, is change the labels at some point, making non-native Mercurial projects the ones being singled out.
As far as existing projects are concerned, we are working on a migration system. It already shows some good results but still needs to be completed.
More information about native Mercurial in Heptapod and the plan to get rid of all conversions to Git can be found in The road to fully native Mercurial in Heptapod.
The close future ahead
With Heptapod 0.25, we are based on an upstream GitLab version that will receive security upgrades for two months from now.
This gives us some headroom to focus more on Heptapod features and less on upstream upgrades. Namely, Heptapod 0.26 should still be on GitLab 14.2, with next upstream version bump in Heptapod 0.27 only.
Here are some topics we may work on in the Heptapod 0.26 development cycle:
- Improving the fully native mode of Mercurial projects. The ultimate goal is naturally to get rid of Git conversions completely.
- Merge Requests in cases where topics are stacked: heptapod#63, heptapod#284, heptapod#366.
- Per-user topic namespaces, making it possible to contribute without the Developer role.
If you are interested in contributing to these subjects, don't hesitate to contact us, for instance in the "Development" Mattermost channel, or simply by commenting on the relevant issues.
With roughly 5 weeks of development time and maturation, it is very very likely that Heptapod 0.26 will provide these features in a partial form, perhaps with explicit activation, but we hope to make good progress. There are also lots of smaller improvements waiting in the backlog.
Thank you for reading so far, and happy heptapoding.