Skip to content

Releases: sociomantic-tsunami/makd

v3.0.1

01 Dec 13:20
a21f5ef
Compare
Choose a tag to compare

This patch release fixes a major bug in the Version.d.tpl file which resulted in invalid D code being generated for the Id template.

v3.0.0: Drop support for D1, rename production to prod

01 Nov 15:28
Compare
Choose a tag to compare

This release comes with two breaking changes:

  • First, all D1 support and mentions have been removed,
    as no project is known to still use D1.

  • Second, for consistency, the production flavor has been
    renamed to prod, so it better mirrors dev.
    Those wishing to still use production can add it to VALID_FLAVORS,
    however the defaults that come with prod will not be applied.

v2.2.1

19 Jun 16:22
v2.2.1
2232630
Compare
Choose a tag to compare
v2.2.1

v2.1.4

19 Jun 16:22
v2.1.4
Compare
Choose a tag to compare

https://github.com/sociomantic-tsunami/makd/milestone/47?closed=1

  • git-deblog: Fix multiple tags for one commit warning #125
  • Save test binaries #124

v2.2.0

22 Feb 21:24
v2.2.0
Compare
Choose a tag to compare

https://github.com/sociomantic-tsunami/makd/milestone/40

Features

Coverage support

Now MakD will handle compiling and running with code coverage if COV=1 is
used. This should be provided for both compiling and running tests. Please
refer to the documentation for more details.

Full support in only provided by the following DMD runtime versions (merging
coverage reports support is needed for this to work properly):

  • dmd1: tangort v1.8.0+
  • dmd-transitional: v2.070.2.s15+ and v2.071.2.s4+
  • dmd: v2.078.0+

The package iteration can now be specified via PKGITERATION

Package versions consist of two components: the upstream version, and
the package iteration (corresponding to the debian_revision where
deb packages are concerned).

Previously the package iteration was hardcoded to match the distro code
(e.g. xenial), disallowing typical patterns referencing the packager
and changes to the packaging rather than the upstream project.

The new PKGITERATION variable allows the package iteration to be set
to whatever is wanted, whether via Config.mak or the command line.
It still defaults to the distro code, meaning nothing will change for
existing package definitions, but can now be customized where this is
appropriate (e.g. for packages of 3rd-party projects).

Note that if you want to include the distro code in a customized package
iteration, this will have to be included manually. For example,
PKGITERATION=3~"$(lsb_release -cs)" will produce iterations such as
3~trusty, 3~xenial, etc. depending on the distro used to build the
package.

For some examples of how to set the package iteration, see the
Debian versioning policy
and the Ubuntu debian_revision schema.

v2.2.0-rc.1

13 Feb 14:43
v2.2.0-rc.1
Compare
Choose a tag to compare
v2.2.0-rc.1 Pre-release
Pre-release

Features

Coverage support

Now MakD will handle compiling and running with code coverage if COV=1 is used. This should be provided for both compiling and running tests. Please refer to the documentation for more details.

Full support in only provided by the following DMD runtime versions (merging coverage reports support is needed for this to work properly):

  • dmd1: tangort v1.8.0+
  • dmd-transitional: v2.070.2.s15+ and v2.071.2.s4+
  • dmd: v2.078.0+

The package iteration can now be specified via PKGITERATION

Package versions consist of two components: the upstream version, and the package iteration (corresponding to the debian_revision where deb packages are concerned).

Previously the package iteration was hardcoded to match the distro code (e.g. xenial), disallowing typical patterns referencing the packager and changes to the packaging rather than the upstream project.

The new PKGITERATION variable allows the package iteration to be set to whatever is wanted, whether via Config.mak or the command line. It still defaults to the distro code, meaning nothing will change for existing package definitions, but can now be customized where this is appropriate (e.g. for packages of 3rd-party projects).

Note that if you want to include the distro code in a customized package iteration, this will have to be included manually. For example, PKGITERATION=3~"$(lsb_release -cs)" will produce iterations such as 3~trusty, 3~xenial, etc. depending on the distro used to build the package.

For some examples of how to set the package iteration, see the Debian versioning policy and the Ubuntu debian_revision schema.

v2.1.3

15 Jan 13:53
v2.1.3
a3b4da2
Compare
Choose a tag to compare

v2.1.3

v2.0.4

15 Jan 13:53
v2.0.4
Compare
Choose a tag to compare

v2.1.2

08 Dec 16:22
v2.1.2
430cd09
Compare
Choose a tag to compare

v2.1.2

v1.11.2

08 Dec 16:22
v1.11.2
a8fc56f
Compare
Choose a tag to compare