NuGet
NuGet.org should allow uploading packages with same version number if only meta data has changed
NuGet Product(s) Involved
Other/NA
The Elevator Pitch
I just uploaded a package to NuGet.org, just to notice that I had something to refine/improve in the packages ReadMe.md file.
Now, I want to replace the original package in-place. I'd just upload the amended version, without increasing the version number of the package. It's just meta data that has changed in the package.
Please allow for uploading an amended package with non-critical updates.
Additional Context and Details
No response
Please check https://github.com/NuGet/Home/wiki/Package-Immutability, official policy. At least you need change version suffix. Many of the features in nuget echo system such as lock files are created on above assumption. Changing this policy would cause many cascading issues, including supply chain security.
I comprehend.
Yet, changing a package's ReadMe.doc file wouldn't cause a difference if there'd be a dangling "old" package somewhere in a cache of CDN. It's just the documentation that changed.
Yes, the use of lock files would be impaired. Yet, eventually, that's exactly what lock files exist for.
To keep NuGet package authors from exagerating on updating their NuGet packages' documentation and similar "non-lib" meta data, amending new package versions could be constrained to a 30 day period after release.
Some ReadMe.md files are embedded in the package. Changing even a tiny bit would not only invalidate the lock file but also cause an SBOM issue, it also immutable by design. IIRC to https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity SBOM should contains everything should be traceable to source materials. For example, if someone creates an asset from PackageA with hash xxxx and later changes it to hash xxyy, it becomes invalid and is no longer a valid SBOM. This adds unnecessary work of continuously checking every dependency for changes over 30 days, it could be hundreds of dependencies.
A better solution would be to publish a new version for each change, making it easier to track what happened.
I see your point. Yet, I believe there is a false assumption on your behalf regarding the interpretation of the three parts
- package name
- package version
- package hash
Let me take the Docker versioning scheme as the template for my argumentation. You may find it here: https://docs.docker.com/reference/cli/docker/image/pull/#pull-an-image-by-digest-immutable-identifier
I fully agree with you that changes in package content should require a new version number. Yet, I'm arguing about meta data here, i.e. the package's ReadMe.md file. My point is that typo fixes in the ReadMe.md (or similar meta data files) should not require to publish a new version while keeping the unfixed version around in the wild. This is something that cannot be tested by automation, and often a third person notices typos the author (or the whole team) missed while writing.
In regard to above meta data – not the critical package content –, let's differentiate between two kinds of package identifiers: package name and package version on one hand and package hash on the other.
In regard to above meta data, the combination of package name and package version should be considered "weak identifiers", i.e., if someone refers to a package using package name and package version, NuGet.org should serve the latest version that is available using this key.
On the other hand, the package hash is a "hard identifier", i.e., if someone refers to a package using the package hash, NuGet.org should serve whatever is available using this key.
As a conclusion: packages referred to by package name and package version may deliver other content than packages referred to by package hash.
It's so easy.
The business rules on the NuGet.org server just must verify that critical package content did not change when an existing package name/package version package is uploaded, rejecting such changes for an existing package.
My point is that typo fixes in the ReadMe.md (or similar meta data files) should not require to publish a new version while keeping the unfixed version around in the wild. This is something that cannot be tested by automation, and often a third person notices typos the author (or the whole team) missed while writing.
IMO, having a version with typos or mistakes is fine; everyone makes mistakes. The solution is to simply deprecate it and publish newer version with fix.
As a conclusion: packages referred to by package name and package version may deliver other content than packages referred to by package hash. It's so easy.
As I mentioned before, due to a decision made a long time ago (predates me), it will break many existing tools. The benefit does not outweigh the issues it causes. Besides, it adds another layer of complexity. The current id+version has a unique 1:1 relationship with the nupkg, but making it 1:N makes it very hard to reason about build provenance and SBOM compliance, etc.
I feel that this could be addressed by leveraging the build metadata as defined in semver & it is also what I am wanting to use for https://github.com/NuGet/Home/issues/14170
