We're glad to announce that the first release candidate for Heptapod 0.13 has just been released.
The main user visible feature that this new version brings is the support for project wikis (see details below).
One of the main goals of the Heptapod 0.13 series is to provide a firm basis to the major changes that will happen in the 0.14 development cycle. This means that some core aspects are tighter with 0.13.0rc1 already and it gives us the proper ground to fix some of the current issues.
Heptapod 0.13.0 will also sport two technology previews to help make the transition to 0.14 smoother.
So, please give 0.13.0rc1 a try, even if you don't care about wikis!
The full changelog is available alongside the sources.
Feel free to give us feedback on our communication channels, we value all kinds of contribution.
With 0.13.0rc1, GitLab wikis are expected to work in the Web UI and are backed by Mercurial repositories.
The supported markups are the standard GitLab ones, Markdown, AsciiDoc and RDoc together with limited added support for reStructuredText, a common choice in Bitbucket repositories.
The Bitbucket importer does not yet import the wikis. The final Heptapod 0.13.0 most probably will.
You can clone, pull and push to the wiki repository by adding .wiki to the URL. Some examples:
hg clone ssh://email@example.com/group/proj.wiki hg pull ssh://firstname.lastname@example.org/group/proj.wiki hg push https://your.heptapod.example/group/proj.wiki
The first of these URLS would be typical of a Docker installation (in these, we inherit git as the expected user from the parent GitLab image).
Technology previews in Heptapod 0.13
The Heptapod 0.13.x series will have two "technology previews".
By testing them early, you would help us moving forward towards Heptapod 1.0 while gaining better confidence that the upcoming versions will work well on your projects.
These are not yet included in 0.13.0rc1, but we felt it appropriate to give a glimpse of what will happen so that you can prepare for them.
To recall, Mercurial is written primarily in the Python programming language. Python 2 has reached its end of life this year. The new version of the language, Python 3, has a vastly different and incompatible way of handling strings and their encodings. This is challenging for a version control system which, by definition, must be able to handle content transparently, even if it doesn't have a known and consistent encoding.
Python 3 support in Mercurial has been progressing gradually in recent releases, and we believe 5.4 on Python 3 to be ready enough for inclusion in Heptapod. Also, the last blocker on the road towards Python 3 has been removed earlier this week.
This change warrants an extended testing period, and the means to assess easily if a given problem is related to Python version. Here's the plan:
- Heptapod 0.13.0 and subsequent 0.13.x versions should be able to run with Python 2 or 3
- Python 2 will stay the default at first, this may change after a few intermediate releases.
- on any Heptapod 0.13.x version, it will be possible to switch from Python 2 to 3 and back without changing anything else: we will provide Docker images for both and source installations would only need a restart to switch Python versions.
- Heptapod 0.14 should be for Python 3 only
GitLab Shell is the component responsible for interaction with SSH clients. Originally written in Ruby, it has been undergoing a rewrite in the Go language. This rewrite is fully ready yet still optional in GitLab 12.3, the base version for Heptapod 0.13. It becomes mandatory in GitLab 12.4. That is why we make a stop at GitLab 12.3.
Our Heptapod Shell component is a modification of GitLab Shell that adds SSH support for Mercurial, currently in Ruby only.
In the final Heptapod 0.13.0, we will provide an optional rewrite of Heptapod Shell in the Go language.
This rewrite will become the standard in Heptapod 0.14, allowing us to jump to the most recent GitLab 12 version possible (ideally 12.10 or 12.11).
It should be available for source installations, and possibly also opted in through configuration in Docker setups.