The first step in publishing a new version of your Application is creating a Release:

dblsqd release $version

$version needs to be replaced with a unique name later used to identify this release.

It is typically a good idea to use a naming scheme compatible with Semantic Versioning 2.0. This allows for some additional features such as ordering by version number and targeted delta versions which are described in a later section of this chapter.

dblsqd release interactively asks for a changelog message.
Alternatively, you can specify one or more changelog paragraphs with the -m option.

In this example, there is an Application with two channels: “stable” and “nightly”.

In the “stable” channel, three releases (1.0.0, 0.2.0 and 0.1.0) have been published.

Publishing Artifacts

A Release can contain one or multiple Artifacts.

Artifacts are the files you want to distribute to your users, e. g. installation packages or installers.

DBLSQD is platform-agnostic and allows for a single Release to have Artifacts for multiple operating systems and processor architectures.

You can upload an Artifact with the push command:

dblsqd push $os:$arch $/path/to/artifact

$os and $arch should represent the Artifact’s operating system and processor architecture respectively.

Here is a Channel with three Releases.

Release 1.0.0 has two published Artifacts. Both target macOS on an x86_64 architecture but one of them is marked as a patch for a previous version.

Patches/Delta Versions

An Artifact can be marked as a patch by specifying the --patch option with dblsqd push.

Typically, patches are delta updates to the previous Release.

If you are a versioning scheme compatible with Semantic Versioning 2.0, you can also specifically target the patch at one or more previous Releases with the operators familiar from package managers such as npm, gem or hex.


--patch 0.1.1 denotes a patch that should be applied to the release 0.1.1.

--patch "~> 0.1" matches all versions that are greater or equal to 1.1.0 yet smaller than (not including) 2.0.0.

--patch ">= 1.1.0 and < 1.3.0" matches all versions that are greater or equal to 1.1.0 and smaller than (not including) 1.3.0.

Artifact Types

Sometimes you might need multiple different Artifacts for the same operating system and processor architecture in a Release. This is when you can use Artifact Types.

A typical use case would be a Windows application for which you want to publish a regular .exe installer, an .msi package and a portable .zip version .

The default Artifact Type in DBLSQD is standalone and is always assumed when no other type is specified.

In the case of the aforementioned Windows application, publishing a new Release could look like this:

dblsqd push win:x86_64 octaplay-1.0.0.exe
dblsqd push win:x86_64 octaplay-1.0.0.msi --type msi
dblsqd push win:x86_64 --type portable

Artifact Types also play a role when targeting specific Feeds. More about this in the next chapter of this Guide.

Are you stuck?

Are you stuck or need help setting things up?

Let us know at hello- at -dblsqd com and we’ll be happy to assist you!