We already have four allowed formats for snapshot information. What does this format give us that the existing four do not? I would rather see fewer formats allowed, not more. We've already got too much sprawl on this in practice and should instead work on standardizing the approach used.

In particular, I think embedding the SCM type is completely unnecessary. RPM and DNF only care about the sorting. The vast majority of projects use git, and the ones that don't still have a revision that a user can track down by simply referring to the revision. "It is this revision in the upstream source control" is sufficient for anyone to track down a revision without having the SCM type explicitly listed.

I think the only allowed formats should be:

• <date>.<revision>
• <number>.<revision>

I have been using snapshot info of the form git. for literally almost a decade. I could have sworn that this used to be documented in the guidelines. Is it possible that this has been lost accidentally or was intentionally removed when the snapshot versioning guidelines were rewritten for tilde and caret-based versioning?

It has existed before, we even used git<number>.<revision> with yum at one point, I think?

Oh nope, we just kept bumping the release number to high numbers.

The <scm><date>.<shortcommit> from has existed for a while, though. The reason I used it was because I picked it up from other packages 10+ years ago and it turned out to be semantically compatible across RPM and Debian distributions, especially when using + instead of ^.

We probably should actually get rid of the non-SCM-tagged ones, because it's not always git and sometimes something is available in multiple SCMs simultaneously. A couple of good examples of this are Firefox and OpenSSH. The former is primarily developed in Mercurial for now but has a Git mirror. You can't tell which one it came from by just the hash alone. For the latter, if you use the date-based one, you can't tell whether it came from CVS (the primary location) or Git (the mirror). And that can make a difference because the two systems represent changes very differently.

I have been using snapshot info of the form git. for literally almost a decade. I could have sworn that this used to be documented in the guidelines. Is it possible that this has been lost accidentally or was intentionally removed when the snapshot versioning guidelines were rewritten for tilde and caret-based versioning?

The previous snapshot guidelines are still in the doc under the traditional section.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots_2

In those we only suggested either YYYYMMDD.<revision> and YYYYMMDD<scm><revision>, although more leeway was given for variations. In the switch to having snapshot in Version, that was locked down to the four formats listed.

The . from has existed for a while, though. The reason I used it was because I picked it up from other packages 10+ years ago and it turned out to be semantically compatible across RPM and Debian distributions, especially when using + instead of ^.

We should make the best choice for Fedora regardless of what other distributions are doing. There are many things that make sense to align between distributions, but this ain't one of them.

The . from has existed for a while, though. The reason I used it was because I picked it up from other packages 10+ years ago and it turned out to be semantically compatible across RPM and Debian distributions, especially when using + instead of ^.

We should make the best choice for Fedora regardless of what other distributions are doing. There are many things that make sense to align between distributions, but this ain't one of them.

Version data is absolutely one of those that makes sense to align closer on. Being able to compare things easily to determine where we are relative to each other as a packager and as a consumer is valuable.

We probably should actually get rid of the non-SCM-tagged ones, because it's not always git and sometimes something is available in multiple SCMs simultaneously. A couple of good examples of this are Firefox and OpenSSH. The former is primarily developed in Mercurial for now but has a Git mirror. You can't tell which one it came from by just the hash alone. For the latter, if you use the date-based one, you can't tell whether it came from CVS (the primary location) or Git (the mirror). And that can make a difference because the two systems represent changes very differently.

It's almost always git, and when it's not, there is still a primary. We can cover this edge case by just having a note in the guidelines to use the primary when the source is mirrored to a different SCM type. That's far more reasonable than embedding the SCM in every single package's Version.

Version data is absolutely one of those that makes sense to align closer on. Being able to compare things easily to determine where we are relative to each other as a packager and as a consumer is valuable.

We aren't even aligned on this for comparisons across Fedora, which backs up my point that we should reduce the formats we allow, not increase them.

I think if we are going to try to reduce the number of formats, I'd like to say:

Require scm if it's not "git", and suggest no scm if it is.

...but not sure if it's worth trying to get everyone to use one or two formats, as long as all the allowed ones are readable.
Maybe suggest 1-2 but allow the other 3-4?

I think recommending a couple is fine, I do think that we should not omit the VCS/SCM type, though.

We talked about it today and decided to merge this simple PR, and add anything extra in followup PRs.