@danbst Thanks for your effort.

What is the goal of having a version suffix?

The pre versions are not good because you don't know the next version until it is released. Even if it was announced, a patch release might be needed.

I don't like the YYYY.MM.DD syntax. ISO 8601 defines a standard that is commonly used. It can be recognized as a date and parsed by tools like repology. https://xkcd.com/1179/

Should the derivation name and meta.name differ? Might be less confusing if they don't.

@davidak
Version suffix is part of derivation name, which has special handling in nix-env -u. So if we update a package, but don't bump version (e.g. another Git revision), it should be reflected in name.

But I don't think this nuance should be reflected in Repology. Who even cares about explicit Git revision of a package in repology? That's why meta.name is cleaned up.

The pre versions are not good

I just stick to what nixUnstable uses. Sure, we don't know what next version will be. The alternative is to use 2.3.1+ to relfect we are on explicit revision based upon 2.3.1 version. Would that be better?

I don't like the YYYY.MM.DD syntax. ISO 8601 defines a standard that is commonly used. It can be recognized as a date and parsed by tools like repology. https://xkcd.com/1179/

This is also kinda stadard https://calver.org/ . If repology can recognize this as date, it is awesome, as this is exactly what we want (2019.1.1, 2019.01.01, 2019-1-1 and 2019-01-01 should all be same version).

Might be less confusing if they don't.

We have at least 1 case when meta.name != name, it is when we crosscompile. So I don't think it will hurt to have those different, especially as we publish meta.name.

Version suffix is part of derivation name, which has special handling in nix-env -u. So if we update a package, but don't bump version (e.g. another Git revision), it should be reflected in name.

The comment in #73228 (comment) states that it is not needed:

Nix can distinguish if a package changes based on the hash of the derivation generated by the expression, so it does not need such extra attribute.

(or do i understand it wrong?)

I just stick to what nixUnstable uses.

In this case we are upstream and the pre release version is similar to an official release. So not good to generalize it.

The alternative is to use 2.3.1+ to relfect we are on explicit revision based upon 2.3.1 version. Would that be better?

I think that is very intuitive for a user.

We could add the number of commits since the version (2.3.1+42), but we have to get it somewhere. A package maintainer should not have to count them. fetchFromGitHub gets a tarball when a revision is given, right? When the git repo would be cloned, git can give this information.

I don't know if there is a consensus how to describe unreleased versions best. As always i would get in contact to other distros maintainers since they have the same challenges. @AMDmi3 might also have some good insights. But i think we had this discussion before, here or in repology.

This is also kinda stadard https://calver.org/ .

Ah, yes. Might imply it's an official release. We still need some good word that it's an unstable package version.

And it could cause problems when you compare it to a semver version.

The comment in #73228 (comment) states that it is not needed:

Nix can distinguish if a package changes based on the hash of the derivation generated by the >>expression, so it does not need such extra attribute.

(or do i understand it wrong?)

that is correct, however we have plenty of cases when hash changes, but package source - doesn't. If we have version (source version) and patches info in name, then external tools (such as nix-diff) can show that not only hash had changed, but some patches were also added.

Can we please get rid of the dot stuff and use ISO-dates? calver looks like a BS standard, because it’s basically: “people use different things, so it’s fine to use whatever”. That’s counterproductive …

Is this PR still relevant or is it abandoned?

@uri-canva this proposal of change, it's definitely not about being merged as is. But yeah, given I don't have enough willpower to make it proper RFC, let's close