Release Strategy Ideas

[acholyn]

Loose idea based on discussion in retro july 17:

• portal to tag version number
• version gets deployed
• portal flags tag as ready for release on prod

[acholyn]

portal flags tag as ready for release on prod

I think existence of (non pre-release) github release should imply ready for prod

from: @t-young31

[acholyn]

may want to figure out how frequently to ask accessibility people to play/test

[acholyn]

add instructions to dev docs for how to tag release etc

[t-young31]

My thoughts:

0. Team is happy with state

1. Maintainer pushes a tag from main

git switch main
git pull
git tag v<x.y.z>
git push origin tag v<x.y.z>

2. Maintainer creates a release from that tag with autogenerated release notes

3. Any non-pre release tag will be 'automatically' deployed

[acholyn]

How does 3 work?

[t-young31]

Initial release published: https://github.com/ucl-arc-tre/portal/releases/tag/v0.0.0

[jhughes982]

(coming to this after being away from the project)

It sounds like the release strategy is now somewhat decided? Shall we get this into the main docs? Is the next step to make a ticket for this (i.e. add release strategy to docs)?

[acholyn]

#869 have created it