That’s clear, thanks—and it’s what I was concerned about.
There can be only one NuGet package called ‘Foo’ of version 3.5.2 in a single repository at any given time. Every time you publish something new to (“Foo”, “3.5.2”), you’re overwriting whatever’s alraedy there, just as if you were overwriting a file. You can’t have two files with the same path and file name on the same file system; you can’t have two packages with the same coordinate in the same repository. For NuGet, the “coordinate” is packageId and version.
Although many ecosystems allow it, we highly recommend against republishing binaries with reused coordinates. If at all possible, adjust your development practices to prevent this from happening.
When you visualize the whole pipeline from development, publication, to downstream caching (possibly in multiple business units, or in a tier of load-balanced read proxies), it can be impossible to know if consumers are referencing the “right one,” or (as happened to you) to tell if the wrong one is still lurking around.
Also, it means your historical record is lossy, since you’re not keeping all of the versions you may care about (for audit reasons, etc.)
In this specific case, you might want to hand-edit the July 13 package to have a unique version number. NuGet allows pre-release qualifiers, so you could have these two packages:
Then you can use the UI Upload feature to upload the ‘old’ version to the repository, where it can live alongside the other one because it has a different coordinate.