very high frequency of releases resulting in a lot of churn

[decathorpe]

Preface: $subject is not a "problem" per se - I would have opened this as a Discussion thread if that feature were enabled on this GitHub project. But it's not, so it's an "Issue" instead. Ho Hum.

---

It looks like something changed in the release process a while ago (Or did the people maintaining / publishing the crate change? It's hard to tell, since all releases on crates.io are published by rust-lang-owner.) - the frequency of new releases went way up, as in, previously there was maybe one release per month, and now there are often multiple releases per week. Looking at the release notes for those releases, it seems like a new release is tagged for basically any change or bugfix in cc.

I am a package maintainer in Fedora Linux, and (among a 4-digit number of other crates), I am responsible for the cc crate. I literally can't keep up with this pace of new releases, since package updates spend a minimum of 7 days in QA unless they're manually verified to be good by at least two people (other than the package maintainer themself - and given the number of people who give feedback on Rust crate updates, two upvotes happen almost never).

Would it be possible to reduce the release cadence, maybe to something like "every two weeks" (unless there's security fixes or something)? The current "one teeny tiny release every few days" is a bit too far down the "too little too often" end of the spectrum, at least in my opinion and experience, and creates a lot of churn (especially for a crate that is as widely used as cc).

[madsmtm]

If you don't mind, lemme flip the question on its head, and ask you back: Why does Fedora need to release every new version of cc, and why does it have to be done quickly?

---

In the end, I think it's a balance; it's quite nice to have things out the door quickly, and really nice to have almost a version per PR (makes it much easier to find a regressing PR in a release, which is otherwise quite hard since the maintainers of cc may not be able to reproduce the issue), but I also agree that it doesn't have to be as fast as it is right now.

CC @NobodyXu

[NobodyXu]

Well the release schedule usually depends on how much changes have been made, and if there's any pending PR that will merge soon.

If we had a lot of changes, i.e. like the previous rewrite to use rustc generated info, I would probably cut a release just to make bisecting easier.

If the changes are small and I know there's incoming PR, then I would wait until it is merged.

It is a bit better than the previous model, in that we have to wait for months before a release is cut, and then discovered regressions that force us to yank the release and fix it.

[NobodyXu]

Would it be possible to reduce the release cadence, maybe to something like "every two weeks" (unless there's security fixes or something)?

I can reduce the release to only once a week.

I am not completely against the idea of one release every two weeks, but I personally think getting early feedback is important in catching bugs.

[NobodyXu]

I am responsible for the cc crate. I literally can't keep up with this pace of new releases, since package updates spend a minimum of 7 days in QA unless they're manually verified to be good by at least two people (other than the package maintainer themself - and given the number of people who give feedback on Rust crate updates, two upvotes happen almost never).

Is there anyway we can automate the process of pushing cc-rs to QA?

cc @decathorpe one idea I have is for cc-rs to automatically push new release to fedora QA without having to do anything manually, that should smooth thing up right?

[NobodyXu]

BTW cc-rs really need more testing, review and feedback, but we are short of maintainers.

[decathorpe]

Is there anyway we can automate the process of pushing cc-rs to QA?

cc @decathorpe one idea I have is for cc-rs to automatically push new release to fedora QA without having to do anything manually, that should smooth thing up right?

Theoretically that process can be automated, but it won't help. The delay is not in the preparing of the update, it's that it spends a minimum of 7 days in QA once it's been submitted as a package update, and if you submit another update for the same package within that time period, the previous one gets obsoleted and the timer resets to 7 days.

[NobodyXu]

In that case I can limit the release to one per week, unless there's a regression/compilation failure that might break existing users.

[decathorpe]

Yeah, that would be great. Just to reiterate, I don't think making frequent releases is a problem per se. Just in this case the frequency is so high that it might cause unintended churn elsewhere :)

[NobodyXu]

Thanks for letting me know, I will keep a one-week release schedule then.

Shall we close this issue now?

[madsmtm]

Perhaps close it with a documentation update?

[madsmtm]

Or some update to the release-plz configuration that helps with it? Perhaps just a change so that there's a reminder note in the PR generated by that (if that's possible)

[decathorpe]

Great, thank you!