publishing backported crate versions
danieleades opened this issue · 4 comments
i believe that in the current implementation, it is an error to upload a crate if there is a newer version in the index. Is that correct? Does crates.io behave the same way?
this precludes backporting fixes to older versions.
consider this use case
- release and publish a major version of a library (eg 1.0.0)
- release a a new major version of the library (eg 2.0.0)
- fix a bug.
- release patch versions of the last 2 major versions (eg 1.0.1, 2.0.1)
similarly for backporting features (which would be a minor release on an older major release)
currently, i think it would be impossible to publish the 1.0.1 version in the above example.
It is not always possible to force library users to upgrade to a new major version
it seems to me that the correct logic would be to allow publishing any version of a crate provided it is the latest version for a given major release (as opposed to the globally latest release).
Oops, this use case did not cross my mind at all, that's a very good point.
After looking at the crates.io source code for publishing), they seems that they don't have any real check on the crate's version, they just attempt to insert it into the database and see if it fails (if it already exists).
So, removing that check entirely could also be sufficient for us I guess, but I like your proposition to have that check be per major version, I think it would solve this very neatly, indeed (publishing a 1.1.0 while a 1.2.0 existed would not make much sense, as cargo would always choose 1.2.0 when doing cargo update).
You could take a look at how I solved this in my index crate
The premise is to store the records in a binary tree, rather than a vector, which lets you do efficient range lookups.
Is there any update on this ?
The fix for this issue is going live right now.
I'm really sorry for this way too long wait.