Simplify release process, use the Github UI for release

[rfay]

I created a release today to solve the keepalive_workflow problem, but didn't properly follow the docs

I recommend that we simplify those things so that the release workflow gets run "on release", so that any maintainer can do it with less risk.

Since I did it with the github UI, a release was created, but the v2 tag was not moved properly.

[julienloizelet]

I think the current process is better (and not more complicated) than using the GitHub UI release process.

The main difficulty is that every maintener should be aware of the existence of such a process. I though the documentation was enough: I was wrong.

So, for me, it's more a problem of communication than of the actual process. Again, I apologize for bad communication.
(Just in case, I'm using the same kind of release process for every DDEV add-on I maintain :) )

I think the current process is better because it ensures that:

• the code is consistent with the new version number:
  • in the CHANGELOG (must be up to date)
  • in the README (major tag must be the correct one).

But the main reason I prefer it to the GitHub UI release process is that it reduces to almost zero the possibility of a typo in the version number when the maintainer publishes the release.

For there to be a typo in the version number, the same mistake would have to be made in CHANGELOG: highly unlikely.

With the GitHub UI process, you can make a typing error at any time, since carelessness is always a risk.

Having said that, I'm not against an alternative release process. So if someone wants to set up an “on release” workflow, that's fine with me.

I wish GitHub would offer a “before_release” workflow that would allow us to do the necessary checks BEFORE releasing; unfortunately, I haven't found anything like that.

Thanks!

[rfay]

You're the maintainer and a very much appreciated maintainer.

Perhaps the UI-based release workflow could be blocked, not sure.

Maybe if you think of a way to use the more expected workflow in the future it can be done.

[stasadev]

From what I see in:

• Update branch tags only when releases are made github-action-setup-ddev#38

That might be the answer here too. Reopening.

(P.S. I already forgot about running a specific action here instead of creating a release.)

[julienloizelet]

From what I see in:

* [Update branch tags only when releases are made github-action-setup-ddev#38](https://github.com/ddev/github-action-setup-ddev/pull/38)

That might be the answer here too. Reopening.

(P.S. I already forgot about running a specific action here instead of creating a release.)

Indeed, updating the major tag on the "release published" trigger should work.

As I've already mention here,
I'm not against an alternative release process and if one want to set up an “on release” workflow, that's fine with me.

It doesn't ensure:

• CHANGELOG is up-to-date (but the CHANGELOG is already outdated, it looks like having a maintained CHANGELOG is not so important, we could even remove it.)
• README is up-to-date. README is not a part of the public API so it's probably not important too. We'll forget to update it when a new major tag is needed until someone creates an issue "Major tag in README is not up to date", but it will be easy to fix.
• There is no typo in the release tag. Well, I hope it won't happen.

but that's fine with me.

[stasadev]

I will research and test this in a fork. I don't feel like doing it now, but I will.

[rfay]

The problem is not that there's anything fundmentally wrong with the existing approach, it's just that nobody can remember to do it the right way.