feat(pkgs/dmd): 2.103.1, 2.104.2 and 2.105.2 (take #2)

[PetarKirov]

This is continuation of #19 by @dukc.

(I would have preferred to reopen #19, but GitHub wouldn't let me since I pushed to the PR branch while the PR was closed.)

[PetarKirov]

@dukc I've rebased your branch on top of the latest main and I've dropped the pkgs/dmd/2.10{3,4,5}.nix files, as they're redundant with pkgs/dmd/supported-source-versions.json.

You can build these packages like this:

nix-build -A packages.x86_64-linux.dmd-2_103_1
nix-build -A packages.x86_64-linux.dmd-2_104_2
nix-build -A packages.x86_64-linux.dmd-2_105_2

For reference, here's the diff with the last commit (a9313a733a62f7d6e9c3bebfd529d45b3a91a7eb) you had pushed to the branch newer-versions in #19:

git diff a9313a733a62f7d6e9c3bebfd529d45b3a91a7eb --stat -- pkgs/dmd
pkgs/dmd/2.103.nix | 6 ------
pkgs/dmd/2.104.nix | 6 ------
pkgs/dmd/2.105.nix | 6 ------

[PetarKirov]

One small improvement idea though, for future: maybe the package names work better without the patch version, meaning packages.x86_64-linux.dmd-2_103 as opposed to packages.x86_64-linux.dmd-2_103_1. We're not going to support different patch versions anyway, only the newest one, right?

Thanks for raising this question! I plan to do the following:

• Finish the rewriting of the fetcher scripts. The most important parts are:
  • Automatically query the git tags for each package, to avoid the need for user to specify them. It should be possible to run the script completely unattended (e.g. dub run -- --min-version=1.05.0 --component=ldc, which should download every single git tag after v1.05.0). We can then add a cron job which will check for updates every day and if so automatically open a PR with the hashes for the new version. That way we can ensure that we support the latest releases as soon as they're tagged.
  • Use the semver dub package (already started that in scripts/update.d) to compare version in order to pick the latest one for a given minor version. Add a new field latestVersions in version-catalog along the lines of:

    {
    "latestVersions": {
    "latest": "2.107.0",
    "2.107": "2.107.0",
    "2.106": "2.106.1",
    "2.105": "2.105.3",
    "2.104": "2.104.2",
    ...
    }
    }

    which will allow us to expose aliases, so a user can just do:

    nix run d#dmd
    # or
    nix run d#dmd-2_105

We're not going to support different patch versions anyway, only the newest one, right?

Actually, once we have scaffolding in place, I see no reason why we couldn't support every single patch version, except for the amount of work involved. That said, even the work is not that much, given that once you've done the work to support 2.xxx.0, your pretty much done for every subsequent patch version as well.