We're especially proud to announce the final release of Heptapod 0.14.0, catching up onto supported upstream GitLab versions.
Many thanks to all our contibutors, and especially for those involved in user support on foss.heptapod.net – lots of Bitbucket imports in the past few weeks!
Indeed, Heptapod 0.14.0 is based on GitLab 12.10.11, that should get security updates until July 22th, 2020. We should now be able to follow GitLab security updates with Heptapod point releases.
With Python 3 becoming the default in Heptapod 0.14, we have a fully current software stack.
The current Heptapod Runner 0.2 can run jobs for Heptapod 0.14, but the natural companion version will be Heptapod Runner 0.3, to be released tomorrow.
The full changelog is available alongside the sources. Like we've done before, it gives first a summary of the major changes from 0.13.2, with details given in the entries for the successive release candidates.
Actually, most of the work since Heptapod 0.14.0rc1 has been about tightening bolts in the Bitbucket importer.
Other benefits of being on current upstream
While security considerations are enough in themselves to justify the catchup effort, there are many more sides to this achievement. Truly, a new era opens up for Heptapod.
Being closer to upstream is not only about code
Many resources about a project in active development are more consistent in the present than in the past. This applies to ongoing issues, documentation, and even to the people themselves, as remembering past knowledge scattered in many technical areas at a given point in time is a challenge indeed. Of course, there are tools to overcome that, e.g., VCS revisions and tags, changelogs, issue milestones, versioned documentation, but this is still friction.
Overall, it will be much easier for us to engage with upstream, now. Obviously, we are in a much better position to contribute to GitLab.
Some of the foundational tasks that are still ahead of us will become simpler. Previously, we had to assess what GitLab had done in the two years that we were lagging, plus where they are currently going and ajust our plans accordingly, assuming that was even possible. All of this took time, and we had to make some choices that we wouldn't have made in other circumstances, especially if we knew that a proper solution for a given problem would be obsoleted a few versions ahead.
All of this is much simpler now. The differences between Heptapod and upstream GitLab will be easier to grasp for our users, the documentation more easily relevant, and upstream issues easier to find.
Staying current will now be easier
The sheer volume of upstream GitLab updates is staggering. For instance, we measured almost 15 000 modified files between GitLab 12.3 and 12.10. Granted, most of that has nothing to do with the VCS support, but it is still impressive.
In January 2020, about the time we launched foss.heptapod.net, Heptapod was at version 0.8.0, based on GitLab 10.5.8 (2018-04-24), which itself a stable update for GitLab 10.5 (first released on 2018-02-22). With GitLab 12.1 released in April 2020, this means that we had to adapt to 26 months of upstream development in 5.5 months, all the while taking care of existing instances and providing the corresponding exceptional data migrations.
Speaking with data migrations, we will now be on the normal procedure: users will have to spend at least a few days on Heptapod 0.14 (GitLab 12.10) before they proceed to Heptapod 0.15 (Gitlab 13.x).
As far as the development goes, soon, we'll just need to adapt Heptapod at the same pace as upstream GitLab produce versions. This means in turn that more time can be dedicated to features, development tools and documentation… and growing the community.
Why just "soon", and not "from now on"? We still have one last step to climb: from GitLab 12.10 to 13.1 in three weeks. Since that is a major version change, we can expect it to be bigger than just two monthly releases.