Discussing our crates.io publishing policy #351
Labels
No Label
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#351
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context - This subject has been brought by @teutat3s on our Matrix channel after discussing #350.
Issue - Garage v0.7.1 and v0.7.2 are not published on crates.io but they are released on our Gitea. As a more generic question: why some Garage releases are not published on crates.io?
Why are we doing that? - We know that the process of publishing on crates.io is a bit tedious. We discussed about automating it but we concluded that it was desirable to keep it manual but I can't remember why.
Should we change? - This issue has been reported because the ShortOpt lib we use reports Garage version by looking at the crate version, which is, in the end, very misleading for users. This problem can be fixed without changing our publishing policy. Do we see other issues implied by missing releases on crates.io?
Comments by LX:
how to avoid publishing something wrong ? (remember we can't ever change something once it's on crates.io)
do we have examples of other rust projects that have automated publishing their crates, and are there any lessons to learn from there ?