It means you release whatever you have first thing and then release a bunch of patch releases on top as the QA (outsourced on users, probably) results come back.
Sans security patches, why are your features not sized to roughly a sprint? What do you manage to prepare, build and validate in a day or two? To me release cadence less than every few weeks screams "whatever landed in master is good to go" and is a sign of mis-/un-managed development.
Yeah, could be user feedback. And if it's a public beta release why not?
3 devs working for 5 days on each their feature means 3 releases per week.
For the last 10+ years I have been working on the same project with 2 releases per year, so what do I know. But I have used projects with quick release cycles that work very closely with the community. Push new beta, feedback on discord. Was also fine from my (limited) perspective.
Because they should be spending one day writing scripts and github actions for their CI/CD system before pushing out new code by hand or AI assistance several times a week.
Releasing 1 - 3 times a week means it's 1 - 3 times more important to have a deterministic release process than if you release 1 time a week.
Sans security patches, why are your features not sized to roughly a sprint? What do you manage to prepare, build and validate in a day or two? To me release cadence less than every few weeks screams "whatever landed in master is good to go" and is a sign of mis-/un-managed development.