What to cut from our release procedure to simplify it?

[wenzeslaus]

One way of making the release procedure simpler and thus reducing the maintenance burden would be to stop doing certain tasks in the release procedure.

Stop producing Release Candidates?

Are you testing release candidates? Should we just release and then, if needed, fix the release with a next patch/micro release (x.y.Z)?

With not producing RCs, we could also write release news and email announcements only for feature (major and minor) releases (X.Y.0). This means first release (major or minor) has the big announcement, the rest is fixes (patch releases) without big announcements.

Stop producing /grassXY/source?

Do we need the following? Are GitHub + Zenodo not enough (common platform + DOI-level preservation)?

Current release procedure sort of wants this to be created before the release. Maybe we can at least soften the requirement to just do it afterwards. Maybe remove the snapshot directory in addition to it? We can also reduce the files there. AUTHORS basically links to GitHub at the beginning for "GRASS 7+ major project contributors", rest is historical, so the whole file never changes.

Stop updating the Trac and GRASS Wiki?

GRASS Wiki had the latest release listed on the main page. Not anymore. But I think the updated of Cmd still applies, or is that solved with grass-stable now?

Trac has a list of all releases. Last updated for 8.4.0. It also has a macro.

Do you see anything else which would be a good candidate?

Some things may still be improved through scripting and CI, but at the end of the day, if things are not there, there is nothing to worry about in a procedure or a script.

[wenzeslaus]

Notes from May PSC meeting:

• RCs are used by packagers
  • Bas is using RCs for Debian
• At least make the RCs required only for feature releases
• Remove Trac from the release procedure