Skip to content

Conversation

@patrickelectric
Copy link
Contributor

No description provided.

@mbuesch
Copy link
Owner

mbuesch commented Dec 4, 2025

Thanks for your PR. I much appreciate it.
However, I don't really want to do binary releases for any of my projects.

Doing binary releases adds special responsibility and workload that I can't really handle all by myself.
Adding a GH action to automatically build releases is one thing, but maintaining the released binaries adds huge responsibility and workload. Think of security bugs in crate dependencies.

Especially as Rust projects are almost trivial to build I don't think there's a big benefit for users as well.

I would rather like to keep the task of building and packaging to distributions and I would like to focus on source development and distribution instead.

@patrickelectric
Copy link
Contributor Author

Thanks for your PR. I much appreciate it. However, I don't really want to do binary releases for any of my projects.

Doing binary releases adds special responsibility and workload that I can't really handle all by myself. Adding a GH action to automatically build releases is one thing, but maintaining the released binaries adds huge responsibility and workload. Think of security bugs in crate dependencies.

Especially as Rust projects are almost trivial to build I don't think there's a big benefit for users as well.

I would rather like to keep the task of building and packaging to distributions and I would like to focus on source development and distribution instead.

I fully respect your position. Maintaining released artifacts comes with some responsibility..

Still, speaking from experience across several open-source projects, having optional automated binaries can be a huge win for the community with CI doing the heavy lifting..

But to be clear, your boundaries are valid. Just sharing the perspective that binary releases can help users while keeping the maintenance overhead manageable and entirely opt-in.

To share my use case, I would like to have the binaries available to test it with my hardware, and I deal from a raspberry pi 0, some underground linux based SBCs and normal x86 machines. Imagine if I need to build this project every single time that I need it.. Imagine building in a raspberry pi 0, os taking care of cross compilation and rsyncing my way. Have the binary provided by CI is having the project a wget distance.

@mbuesch
Copy link
Owner

mbuesch commented Dec 4, 2025

Thanks for sharing your use case.

Yes, I do understand that building Rust applications on underpowered hardware is a real pain.

Shouldn't we try to solve this problem on a higher level, instead of requiring all projects to provide pre-built binaries for all kinds of underpowered platforms?
Why can't cargo conveniently cross-build an application for arbitrary targets out of the box?

And if I were to provide pre-built binaries, then the Windows platform would certainly have to be part of it. I think there's the most benefit for users.

@patrickelectric
Copy link
Contributor Author

Thanks for sharing your use case.

Yes, I do understand that building Rust applications on underpowered hardware is a real pain.

Shouldn't we try to solve this problem on a higher level, instead of requiring all projects to provide pre-built binaries for all kinds of underpowered platforms? Why can't cargo conveniently cross-build an application for arbitrary targets out of the box?

And if I were to provide pre-built binaries, then the Windows platform would certainly have to be part of it. I think there's the most benefit for users.

There is https://github.com/cargo-bins/cargo-binstall.. that'll work if there is github releases..

@patrickelectric
Copy link
Contributor Author

And if I were to provide pre-built binaries, then the Windows platform would certainly have to be part of it. I think there's the most benefit for users.

I can add that, np

@patrickelectric patrickelectric changed the title github: ci: Add deployment for the 3 major architectures github: ci: Add deployment Dec 5, 2025
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
@patrickelectric
Copy link
Contributor Author

@mbuesch Added windows deployment and template for macos, I can help with macos support later once my PR's get merged.

@patrickelectric
Copy link
Contributor Author

Binaries available here for test: https://github.com/patrickelectric/disktest/actions/runs/19961973841

@patrickelectric
Copy link
Contributor Author

ping @mbuesch

@mbuesch
Copy link
Owner

mbuesch commented Dec 9, 2025

Thanks for adding that. I appreciate it.
But I think there was a misunderstanding here. I said if I were to provide pre-built binaries, then the Windows platform would....

As I said, I am not against binary distribution. Not at all.
I would really like to see this happen. But it will not be me. I simply cannot handle that.
I do binary releases for certain very carefully selected packages. But disktest is not really going to become one of them.

That said, I will support everybody who wants package disktest or any other app for distribution.
I am Ok with applying any change (CI or anything else) that is required for this or supports this, except for the final binary deployment step.

I am very sorry to have caused wasted time on your side.

@patrickelectric
Copy link
Contributor Author

is it ok if I distribute via my repository ?

@mbuesch
Copy link
Owner

mbuesch commented Dec 10, 2025

Yes, surely I would endorse that and I would welcome your work and your effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants