Heptapod 0.6.0 released
We're glad to announce the release of Heptapod 0.6.0, on Docker Hub. This version adds workflow and import features, and makes contributing easier.
While the 0.5 series was mostly about fixing the automatic detection of merges done by pushing public changesets directly from the command line, this new version should allow Heptapod user base to grow beyond its current core of early adopters, thanks to two important user features:
- The intended default simple and elegant workflow is provided out of the box.
- The standard GitLab "import from URL" feature has been finally ported to Mercurial.
On top of that, we made some preparations to make it easier to contribute to Heptapod (lots of low hanging fruits in the UI!), had a minor base GitLab version bump for the first time, and of course fixed a handful of bugs.
A traditional changelog is provided in the full description of the Docker image, with emphasis on backwards compatibility. In the remainings of this post, we'd like to focus on the possibilities that this new version opens.
Workflow
The creators of Heptapod had this vision from the beginning of the project: not only to provide the Merge Request centric workflow that is currently the paradigm of open development but also to have it integrated by default with the non-destructive history rewriting capabilities of current Mercurial with changeset evolution and topics: safe and easy squashes, splits, rebases, you name it. No need to be a DVCS expert, no need to jeopardize a whole project by force pushing on a regular basis.
This is done by a series of server side decisions. All of these are explained and motivated in the Heptapod workflow blogpost. The end result is that
- topics are for short-lived feature branches, they are fully rewritable (draft phase).
- non-topic changesets are completely immutable, as in traditional Mercurial, and writable to the project Master role only.
For projects that can't or won't work in this way, be it for deep reasons or transitional in nature, the server-side settings that enforce this can be changed, see the FAQ workflow section </pages/faq.html#workflow.
Import from URL
Because of various timeouts that can't be reasonably set to very long values, creating a new Project by a direct push is not realistic for large projects. Fortunately, GitLab comes with the machinery to import from various Git sources, and in particular from BitBucket.
In this version, we started with the most generic import: creating a Project by the HTTP URL of a remote repository.
The "import project" tab of the Project creation page, after selection of "Hg repo by URL"
People interested into migrating from Bitbucket and needing to carry issues, merge requests etc. over can already use it for an early test, knowing that the full Bitbucket import is probably just around the corner.
Limitations
This Mercurial import is rather young and we know there's a good variety of pathological cases around, so we don't expect it to work in all situations.
- the import feature has its own timeout, set by default to 800 seconds, that can be modified by the instance's systems adminstrator.
- the import can fail on repositories with instability orphan changesets, divergent ones. Try and have the most of instability resolved before importing.
We'll fix problematic cases in the forthcoming releases, but for that, we need them to be reported on https://dev.heptapod.net, and if it's about publically available repositories, you won't even need to send us the logs, the URL will be enough.
Development process
Various actions were taken to make it easier to integrate external contributors and to streamline our development.
Project management
In this cycle we also started to
- rework our milestones. These will serve as a roadmap for the time being, but we won't hesitate to postpone issues.
- put labels on our issues
Developer tools
- the full description of the heptapod-dev Docker image will serve as a contributor's guide
- the build-launch script makes it easier to get working on a local Docker container.