treewide: replace 0.0.0 versions with 0.1.0

[trueNAHO]

Replace 0.0.0 versions with 0.1.0, as it is the expected initial
version:

> # How should I deal with revisions in the 0.y.z initial development
>   phase?
>
> The simplest thing to do is start your initial development release at
> 0.1.0 and then increment the minor version for each subsequent
> release.
>
> -- "Semantic Versioning 2.0.0", "FAQ", https://semver.org

[danth]

The version number 0.0.0 was used here to indicate that a version number is required, but we don't actually update it when the theme is changed.

This would be difficult to do correctly, because the version number should in theory be incremented every time the content of the theme is updated, but this varies depending on user configuration.

[trueNAHO]

The version number 0.0.0 was used here to indicate that a version number is required, but we don't actually update it when the theme is changed.

This would be difficult to do correctly, because the version number should in theory be incremented every time the content of the theme is updated, but this varies depending on user configuration.

AFAIK, the 0.1.0 version is commonly used to indicate some version without further meaning. For example, some projects stay on 0.1.0 for a very long time, and sometimes forever, because it avoids reaching 1.0.0 upon which breaking changes are supposed to (tediously) update the version. Staying on 0.1.0 without incrementing to 0.2.0 implies that the version is not updating any time soon and therefore essentially useless in the context of semantic versioning. It is essentially a semver loophole.

[trueNAHO]

Friendly ping: @danth

[danth]

Personally I prefer using something which is explicitly not semantic versioning at all, to indicate more clearly that we won't be updating the version number. If 0 or some arbitrary string is valid, that would be an even better option.

[trueNAHO]

Personally I prefer using something which is explicitly not semantic versioning at all, to indicate more clearly that we won't be updating the version number. If 0 or some arbitrary string is valid, that would be an even better option.

Here are the Nixpkgs guidelines:

These are the guidelines the version attribute of a package:

• It must start with a digit. This is required for backwards-compatibility with how nix-env parses derivation names.

  Example: "0.3.1rc2" or "0-unstable-1970-01-01"

• If a package is a commit from a repository without a version assigned, then the version attribute should be the latest upstream version preceding that commit, followed by -unstable- and the date of the (fetched) commit. The date must be in "YYYY-MM-DD" format.

  Example: Given a project had its latest releases 2.2 in November 2021 and 3.0 in January 2022, a commit authored on March 15, 2022 for an upcoming bugfix release 2.2.1 would have version = "2.2-unstable-2022-03-15".

• If a project has no suitable preceding releases - e.g., no versions at all, or an incompatible versioning or tagging scheme - then the latest upstream version in the above schema should be 0.

  Example: Given a project that has no tags or released versions at all, or applies versionless tags like latest or YYYY-MM-DD-Build, a commit authored on March 15, 2022 would have version = "0-unstable-2022-03-15".

-- Nixpkgs, /pkgs/README.md

Otherwise, should we just remove the version comment in /modules/discord/template.nix? We could also remove the version field in /modules/vscode/{hm.nix,package.json}, if it is optional.

[0xda157]

ACK, I do agree that using 0 or even removing the version all together if possible would be best. @trueNAHO there is a merge conflict fyi.

[trueNAHO]

Changelog

v4: https://github.com/nix-community/stylix/commit/4b5fde6dc125d7f3b6f8c5620cd7e36176cdc193

• Bring back commit "treewide: replace 0.0.0 versions with 0.1.0".
• Bring back the theme versions for the /modules/vscode/ module because it either does not build or does not work at runtime. This was tested inside the testbed.

v3: https://github.com/nix-community/stylix/commit/670b78f9a2244acaedf4b18c31acfad555703069

• Remove theme versions instead of standardizing their semantic versioning to further reduce maintenance and avoid documentation drifting.

v2: https://github.com/nix-community/stylix/commit/04d6bfe9a08e8261ed11918d4645ed150d3f151d

• Rebase on top of commit e4fde51c6e56 ("tofi: add missing lib module argument (#1370)").

v1: https://github.com/nix-community/stylix/commit/4749a4cb0a4c27f7175d5a6918dd5f5e842912d7

• Rebase on top of commit https://github.com/nix-community/stylix/commit/603fe2dc7938dd1030da3ed37392b0bfb34222d1 ("treewide: add Flameopathic as maintainer (#1026)").

v0: https://github.com/nix-community/stylix/commit/4f6eb953366d754900cc2973e7bc6c56deed6eb7

[trueNAHO]

• @Flameopathic, could you test whether the Discord theme is still applied at runtime in v4?
• @make-42, could you test whether the fcitx5 module still works (evaluation and runtime) in v4?

[Flameopathic]

• @Flameopathic, could you test whether the Discord theme is still applied at runtime in v4?

Theming works on Vesktop :+1:

[make-42]

testing fcitx5

[make-42]

yeah it doesn't seem to work but it doesn't work on main either (i'd be using an old branch prior), because of how the themes are now handled with home manager options... I'll have to dig deeper...

[make-42]

okay it works fine! it couldn't detect my install unless i told home manager about it with i18n.inputMethod.enabled = "fcitx5"; where i only had it installed system wide before.