Discussing our crates.io publishing policy #351
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#351
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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 ?