Project Proposal: Automate patch level releases

Background

Bugfixes are only readily available if new releases are tagged and thus visible to composer. Thus weekly patch level releases of Flow and Neos in the supported branches should be set up.

Value

  • makes bugfixes available in a timely and plannable way
  • builds trust in the project
  • one task less that needs to be done manually

Risks

  • none IMHO

Requirements

3 Likes

Generally really like the idea :+1: spent way too much effort releasing all those releases in the past. A couple of questions though:

  1. Is there a downside to tagging without any changes since the last tag (assuming it would tag regardless)?
  2. 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.
  3. Are you only referring to the repositories managed in the release scripts or also independent packages?
  4. What about announcements (Slack, Twitter, Discourse)? Stop doing them or automate them somehow?
  5. What about closing and creating releases in Jira?
  6. What to do when dev branch is not suitable for release?

Great idea!

IMO we should not release a patch level version if there were no changes

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…

1 Like

Correct.

:+1: just make sure to change the download page to suit that as part of the project

Knowing if a release failed or was unnecessary would be difficult, but probably not an issue.

I like this proposal very much and I fully support it. It bring tremendous value and add confidence for everyone using Neos when there are weekly releases. Big thumbs up!