Please provide a new release

[Be-ing]

#962 was merged 3 months ago and is not yet included in a release. Because of this, Mixxx CI has to build sccache from source which takes 10 minutes. It is caching the sccache binary for subsequent runs, but the first run of each branch has this 10 minute penalty. This could be avoided if we could install sccache from Chocolatey, which requires a new release.

[Be-ing]

ping

[sylvestre]

Yeah, we will do it soon

[ajschmidt8]

@sylvestre, any updates on the new release?

[dsanders11]

@sylvestre, @milahu, any update on new releases? Anything blocking it that someone else could work? From an outsider's perspective the project has entirely given up doing new releases, since it's been over a year.

[mitchhentges]

Hey David, I'm currently chipping away at the backlog of open PRs to see what can be landed before the next release.

Anything blocking it that someone else could work?

Mostly reviews, there's a few thousands of lines of changed code that needs to be looked through. I'm getting up-to-speed on the project as well.

---

However, something that would be sweet is if we could get the dependencies updated, as it's been a hot minute. There were some patches doing so from a year ago, but if that could be done I'd be pretty happy. While we're at it, tackling modern compiler warnings and clippy lints will be important as well.

[dsanders11]

@mitchhentges, thanks for the response! Happy to hear it's being worked on. I haven't built the project and have no Rust experience, but if you point me in the direction of specific PRs for dependencies, or issues for modern compiler warnings, I could take a look when I get a chance.

I'm mainly itching for a release as I've run into #1098 several times and it might be fixed in master, there are just no releases since then.

[mitchhentges]

The two specific issues I have in mind are #1110 and #1111

I haven't built the project and have no Rust experience

This'll probably be best picked up by more experienced Rust devs since there may be breaking changes that require refactoring.

[Be-ing]

I encourage you not to hold back releases for "one more little thing", especially for not for trivial code cleanup. I've been waiting on a release for around a year now. I don't care about Clippy warnings.

[sylvestre]

@Be-ing please avoid such comments I've been waiting on a release for around a year now. I don't care about Clippy warnings.
They aren't adding any information to the discussion.

[Be-ing]

Fixing clippy warnings isn't adding anything for users.

[sylvestre]

I disagree and please stop bikeshedding.

[Be-ing]

I explained in the first comment that I already setup caching of the sccache build. But that's not a good solution; any time the cache misses, there's a 10 minute cost of rebuilding sccache which negates the benefit of using sccache for that build. Moreover, I just shouldn't need to do that in the first place.

[Be-ing]

Please stop asking downstream users to come up with technical workarounds for your nontechnical problem. There is no need to review every open PR, fix every warning, or update every dependency to publish a new release. If you think there is, that's entirely self-imposed. Version numbers are cheap and releases don't need to solve everything at once. Meanwhile bug fixes from a year ago still have not been released.

[sylvestre]

I am locking this thread. It is becoming useless.

[mitchhentges]

I'd like to add a little more perspective as well here, if it helps things.

I encourage you not to hold back releases for "one more little thing", especially for not for trivial code cleanup. I've been waiting on a release for around a year now. I don't care about Clippy warnings.

Heh, it is an indirect benefit. Either way, this is a red herring: the real blocker isn't clippy warnings, it's that I'm getting up-to-speed with the project. Sure, there's a few commits that are sitting in main ready-for-release, but there's also a significant number of PRs, some of which are ready for landings and some of which need some polish first. I don't know which is which, so my current priority is to work through them and find out.

Keep in mind that it isn't specifically clippy warnings that are blocking the release - I raised this work as something that the community could potentially contribute assistance with while I tackle the other blockers.

There is no need to review every open PR, fix every warning, or update every dependency to publish a new release.

True, one option that exists here is to push out a release based on what's in main, then handle the pending PRs and do a follow-up release afterwards. I'm leaning against this because I don't know the stability state of main, and I don't have enough local infrastructure to raise that confidence. Yes, we have some automated testing, but I'd rather have a more methodical release than to push something out with unknown risk.

By addressing PRs, catching up some issues, and doing some local work, I can build my mental model of the project, which will enable making more confident decisions around releases.

[mitchhentges]

Update:

• Most PRs have been triaged/landed/collaborating with authors (thanks!)/pending responses.
• There's a couple issues associated with the v0.3.0 milestone that will need to be resolved before a release should be deployed. Assistance getting these fixed would be much appreciated.
• I'll do a benchmark run before pushing the release out

We're probably still a couple weeks out, as I'll be away this upcoming week. But, we're getting close. Have a good weekend all 🍻

[mitchhentges]

v0.3.0 is pretty much ready for release, I'm just taming Mozilla's Perfherder to intelligently diff its performance impact.

We'll probably see v0.3.0 released next week.

[mitchhentges]

An issue has crept up during benchmarking, and I'm away tomorrow, so the release will happen next week at the earliest.

[mitchhentges]

v0.3.0 is out

[sylvestre]

Amazing, bravo!