cross-rs
years waiting for new release
Checklist
- [x] I've looked through the issues and pull requests for similar request
- [x] This feature could be solved with a custom image (optional)
Describe your request
Hi!
I rather enjoy the cross utility. In the years since the last release, the Rust compiler has added new platform tiers, as well as patches relating to safety/security. Can we please finally release a new version of cross to account for these enhancements?
I don't understand why so many projects design their deliverables in terms of gargantuan milestones. Would like to see very many incremental updates rather than waiting until the cows come home.
Describe why this would be a good inclusion for cross
This is software, it's not meant to sit idle for years on end. It's meant to change.
I'm not sure what I'm supposed to to with this, but I'll address your points 👍🏼
First of all, this is a open-source project, developed by volunteers with other projects, family, life etc. What this means is that allocation for the regular maintainers can be inconsistent.
In the years since the last release, the Rust compiler has added new platform tiers
Support for these platforms needs the tooling to work and that work to be implemented, this takes time, and if a platform hasn't been supported yet but could be it's simply because time hasn't been allocated towards that.
as well as patches relating to safety/security
I'm not aware of any security patches related to what we control that affects the users (sans one). Users pick the rust version themselves, the version of other libraries to install, etc. You might have a point here with gcc (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189), which is not easy to fix gracefully, and that graceful bump (it would require a update from ubuntu 20.04 to 24.04) can't be done without everything else working around it, which it doesn't always (and doesn't, for example the CI build is currently broken because of a change in ubuntu packages affecting us).
Can we please finally release a new version of cross to account for these enhancements?
Yes, I want this, but stuff needs to be fixed first, and they aren't.
I don't understand why so many projects design their deliverables in terms of gargantuan milestones. Would like to see very many incremental updates rather than waiting until the cows come home.
How does this want apply to cross?
So in general, the big holdup is coordinating Docker image updates, fixing broken CI, and making sure everyone’s use cases keep working.
With all that said, I hear you. Sitting on changes forever doesn't feel good. Cross is volunteer-driven, so my capacity to maintain the project has been limited. If anyone wants to pitch in, that’d help get a release out the door sooner. Until then, I’ll do and have tried to do my best to keep things moving when I can. I try to be very responsive in issues and PRs, and also in our chatroom.
I'll link in https://github.com/cross-rs/cross/milestone/2 too
Hey @Emilgardis, thanks for the detailed explanation for the release holdup, I can definitely empathise with volunteer work not being front of mind.
I will however add to mcandre's post a little bit in saying that if I was to look only at crates.io or the releases page for this repository (which is my normal first look for assessing crate adoption), I would assume that this project had been abandoned with the lack of release activity.
Obviously the maintenance and release cadence of a project is yours to own and control, but I might lightly suggest to reduce the number of features / PRs per release to keep things active. Time gating release cycles like rust-lang does would also be a great option.
Additionally, isolating the maintenance of an image registry to it's own repository could make the release process much lighter and easier to maintain. I'm imagining something that looks like mason.nvim and mason-registry.
I appreciate your work and good luck!
Thanks @baxterjo, I agree with the sentiment and appreciate the post. Currently there's no new features waiting, it's all fixes that need to be implemented.
I think decoupling images from releases would be a good idea. Wouldn't have to be a separate repository just a separate release procedure.
incremental best cremental
what improvements can we backport to the current release series?
I'm not sure I understand the question @mcandre, backporting could be done I guess but I fail to see how it would help the current situation. I myself don't really care about having an updated release with a few ports to just signal on crates.io that there's stuff happening.
the current main version of cross as a binary works well and is perfectly capable of running images from version 0.2.5, the issue is that we can't build those images anymore