Talk:Release maintenance

Daily maintenance workflow

Update Bugzilla (proposed change)

This is very important: let people know you pushed the patches to your stable branch. Add a comment on the relevant bugs like this 'This patch has been pushed to 3.20.x, will be in 3.20.1.' and change the status to Pushed to Stable/oldstable/oldoldstable if you have applied it to your branch.

• We also need a bugzilla field to mark a bug as 'not being backported' to show that a bug has indeed been ssen by the next rmaint in the chain and prevent rmaints from missing bugs during the short release window each month.

Releasing

Update bugzilla (proposed change)

Bugs included in this release should now be marked as RESOLVED FIXED as part of the release procedures.

The simplest way to achieve this is to use the koha-release script after release:

 $ ~/<path_to>/release-tools/bin/koha-release v17.05.00..HEAD updatebz

TODO for work on security release section

• state in the email announcement subject that it's a security release?
• Is it simpler to have 3 separate email announcements instead of 1 by RMaint1?
• change this? "*RMaints change the bug status and add comments after that."
  • Do in advance, like the normal workflow
• «The RMaint1 changes the bug status from security project to Koha project after pushing to master.»
  • RMaint1 (stable) can't push to master right?
  • Is it after the RM has pushed to master? (so, maybe the next day)
  • Or after the RMaints have pushed to their public branches?

TODO ask if changing the Email announcement to just a short text linking to the website

--Victor Grousset - tuxayo 11:13, 23 November 2020 (EST)

TODO ask if announcing the regular releases on Koha devel is useful

.

TODO bump db version number isn't right for >= 21.11.x

.