Tagging releases

[martinjagodic]

Discussed in #6833

^{Originally posted by jessevanmuijden July 3, 2023}
There have been several support requests related to reducing the number of builds, by triggering builds in a cadence that is slower than on every commit. The free plan of some hosting providers, like Cloudflare Pages, is limited to a low number of builds. So, this proposal actually saves money by eliminating redundant builds. Also, there have been many support requests about missing features in the preview functionality. If your website has many custom widgets, a lot of double work is required to display content realistically in the preview window. The current proposal tries to address both concerns, by suggesting the addition of release tagging functionality.

A new main page "Releases" is proposed. On this page, the current version of your project is displayed. Below that, a form with a radiobutton group to indicate whether to bump the patch, minor or major version, and a submit button to update your project's version accordingly and push a tag like release/{version} to the latest commit. This will allow users to disable deployments triggered on the main branch and only deploy on new tags starting with release/*.

This functionality can easily be extended to facilitate separate preview deployments. Imagine a single prominent button to create a new preview by pushing a tag release/{version}-alpha-{lastPreviewVersion + 1} to the head of your main branch. This could be used to trigger a deployment to your preview domain, like preview.yourwebsite.com, based on the tag pattern release/*alpha*.