Summary
Our new, regular release process is running like clockwork. From now on, you can expect alpha releases to be in sync with Dev Pulses. It feels good to get this process implemented!
Highlights
- Release Process: Running Smoothly with Faster Updates and Higher Quality Builds
- Breaking Change: CRUD Validation has Landed
- Core Devs / Bleeding Edge: New Recommended Install Process
- Dev Resources: ‘First Steps’ Tutorial Moved — Updated for 0.0.7
- Challenges: Finding the Right Fit
Details
1. Release Process: Running Smoothly with Faster Updates and Higher Quality Builds
In Dev Pulse 19, we announced that we’d be moving to weekly releases. We shared some of our challenges and growing pains with this new practice in Dev Pulse 20. And today, in Dev Pulse 21, we’re happy to say that it’s rocking our world.
We’ve nailed down the inconsistencies, increased automation, and improved the maturity of our human processes that lead up to a release.
What was once an ad-hoc set of tasks that eventually resulted in green builds and a published binary, is now a checklist that makes every release smooth, consistent, and fairly painless.
What does this mean for developers? It means bug fixes and new features will land quickly. The dev kit binaries are well-tested and assured to install without troubles. And now, everything you read about in the Dev Pulse matches the current release on GitHub.
2. Breaking Change: CRUD Validation has Landed
In last week’s Dev Pulse, we warned of a breaking change to validation callbacks with the introduction of CRUD validation. This has now landed, so it’s time to refactor your validation functions.
Here’s a review of the changes, plus a few new ones since last week’s Dev Pulse. When you define your validation callback, it should accept one argument, an enum of type `hdk::EntryValidationData<T>`, where `T` represents the Rust struct type of the entry being validated. The enum comes in three flavors:
- `Create`, which holds the new entry.
- `Modify`, which holds the old and new entries, as well as the old entry’s header.
- `Delete`, which holds the old entry and its header.
Each of these flavors contain extra validation data, which includes the validation package and information about where we are in the validation lifecycle — committing an entry to chain, receiving an entry as a DHT validator, or updating metadata (e.g., links) on an existing entry.
The signature of the validation function for links has changed to accommodate CRUD as well — ‘CD’ validation, actually, because links cannot be updated. Everything is bundled up in an argument of type `hdk::LinkValidationData`, which comes in two flavors: `LinkAdd` and `LinkRemove`, which both contain the link data and the validation package.
Here’s what’s changed from last week: Previously we said that all of these enum types only contained the validation package. We also erroneously called the `EntryValidationData` struct `EntryValidation`.
Read more about the new validation callback in our API documentation.
3. Core Devs / Bleeding Edge: New Recommended Install Process
If you want to contribute to Holochain itself (either the core, the conductors, or the Node.JS module), or enjoy building bleeding-edge binaries from the `develop` branch — you’ve been cloning the repo and running `make. In this process, you probably struggled through some dependency and path issues. We’re recommending Nix Shell as a new way to get your development environment set up. This is supported on Ubuntu, Debian, macOS, and NixOS.
If you’ve been following the development of Holo Hosting, you may have read that the Holo Hosting OS is built on top of NixOS.
This Linux distro applies strict determinism to package and configuration management. It lets you bundle up a precise environment (or multiple, separate environments) into a script that builds your entire OS for you. We use NixOS to make sure that the hosting OS is set up exactly the way it needs to be.
However, unless you want to wipe out your existing OS or do your work inside a VM, you can’t take advantage of this goodness in your existing development environment. The NixOS team therefore offers Nix Shell, which allows you to create a fully configured environment in which you can run commands in. It’s like Ruby’s RVM or Python’s virtualenv, only it creates an entire mini-OS for you. It’ll set up all the dependencies you need to Holochain from source. Read about the new, Nix Shell-based setup.
Note: If you’re an app developer, you’ll probably still prefer the weekly releases.
4. Dev Resources: ‘First Steps’ Tutorial Moved — Updated for 0.0.7
When Holochain-Rust was finally mature enough to start hacking on, Willem Olding, our developer published an article that helped Holochain-Proto developers get oriented to the new way of building zomes. This article now lives in our developer documentation site, and will get updated as the API changes.
5. Challenges: Finding the Right Fit
As you may know, we’re looking for devs for our core team. It’s a tall order; not only are we looking for strong skills, but we also have to find the right cultural fit. When you assemble a group of people who want to change the world, keep high standards, and meet specific needs — you will almost certainly end up with a rich, but somewhat diverse, company culture.
This, along with the need to make wise decisions, does mean that the process is not a fast one. We want to get it right; new additions to our team need to be a great fit and fully committed for the long haul.
This hasn’t been an easy process, but we feel like we’re getting close. We’re excited about all the fantastic applicants and hope to bring some on board very soon. We’re looking forward to adding to our team so that we can deliver a full-featured alpha and beta even sooner.
