Generally really like the idea spent way too much effort releasing all those releases in the past. A couple of questions though:
Is there a downside to tagging without any changes since the last tag (assuming it would tag regardless)?
What about the website, which in it’s current state needs to be updated manually for each tag? One solution could be to remove that from the website and use the Github API when building a new one for the new website to automatically update that.
Are you only referring to the repositories managed in the release scripts or also independent packages?
What about announcements (Slack, Twitter, Discourse)? Stop doing them or automate them somehow?
What about closing and creating releases in Jira?
What to do when dev branch is not suitable for release?
If no commits happened since the last tag, no patch level release would be done.
For patch level releases the website shouldn’t need to be updated.
Only the “pure” Flow and Neos releases. Unless that misses something important. If we have that working nicely, other package releases could be automated as well, but for standalone packages releasing is as simple as git tag, so that’s not as pressing.
Well, could probably be automated, but for patch level releases I don’t even see a big need to announce them. Especially if they happen regularly and reliably.
Hm, good point. No idea, but that should also be automated. I sure hope there is an API. It would then create a new release whenever the “current” one is closed and assign any closed issue that has no “fix release” yet to the one that is released. Right?
If a branch is not suitable for release, we have a problem! This is only about “stable branches”, not master, so the risk should be low. And if we actually have problems, they should be small (because it’s at most a week of changes going in) and ideally result in improved QA afterwards…