Formalize release process

[danieldaquino]

The release process is manual, and there are enough details that human errors are easy to happen.

I propose that we create a github issue template for the release process, containing a full checklist, and each release is a ticket where we work through the checklist.

[danieldaquino]

What comes to mind for the checklist:

• Make build off of release target (not damus build)
• check CI tests
• Create changelog
• Upload to TestFlight
• Include TF build to Purple group, Translators group and internal contributors/developers
• Make release video and marketing material

After:

• Merge changelog
• Do version bump

[jb55]

On Tue, Nov 26, 2024 at 10:22:40PM -0800, Daniel D’Aquino wrote: What comes to mind for the checklist: - Make build off of release target - check CI tests - Create changelog - Upload to TestFlight

I suggest we look into CI of testflight builds, we don't have to tie marketing to the actual feature release, as most people might not realize new features anyways until we announce them. This would simplify a lot of our testflight iteration and find bugs faster. Not to mention making builds and checking tests would be a non-issue, they would just happen automatically. On the notedeck side I am planning on automating everything. We already have the CI creating notarized dmgs, debs, rpms, windows installers, etc. I'm also planning on auto-changelog generation and github release creatino when new versions are tagged: damus-io/notedeck#495 So with the above ideas, every item on your checklist could be automated. Automate all the things.