The version number of snapshot packages looks something like 0.10.0+3.gade90d0-1670231195+debian11 where the +3 in the middle is the number of commits since the last tag. Some projects force push to the branch used to build snapshot packages from, resulting in this number not being increased. This means the git commit hash is used for comparing two snapshot versions and this is quite likely to not increase with newer versions.
There may be more projects affected, I haven't checked all, just listed the ones where I know they use this snapshot/nightly branch.
These should ideally just push a new commit on top so that the "commits since" number grows leading to increasing version numbers. (The alternative would be to do special handling for this type of repo in the snapshot package version generation, but it would certainly be nicer if now special handling was needed, so I'd say just adding a commit is nicer. This also allows you to just do a regular pull when using the project from a git checkout.)
The version number of snapshot packages looks something like
0.10.0+3.gade90d0-1670231195+debian11where the+3in the middle is the number of commits since the last tag. Some projects force push to the branch used to build snapshot packages from, resulting in this number not being increased. This means the git commit hash is used for comparing two snapshot versions and this is quite likely to not increase with newer versions.Affected repos:
There may be more projects affected, I haven't checked all, just listed the ones where I know they use this
snapshot/nightlybranch.These should ideally just push a new commit on top so that the "commits since" number grows leading to increasing version numbers. (The alternative would be to do special handling for this type of repo in the snapshot package version generation, but it would certainly be nicer if now special handling was needed, so I'd say just adding a commit is nicer. This also allows you to just do a regular pull when using the project from a git checkout.)