Automate release cycle

[mimarz]

Investigate how we can automate release cycle using changesets.

Rough workflow to automate as much as possible

On next branch:

• enter prerelease mode
• develop
• release prereleases (using PR changeset bot)
• When ready for release
  • exit prerelease mode
• release latest (using PR changeset bot)
• publish new app versions to production
• merge next into main to server as snapshot for whats published

[stianmorsund]

Thanks for updating the issue with a rough workflow :)

Do we actually need the next-branch though? Couldn't we just use tags on main? The tags would serve as a snapshot for the state of the repo at time of release. main would always represent the next minor/major-version. If we want to patch an earlier version (e.g in case of needed hotfix), we can just checkout the tag, branch out, apply changes and tag that release.

Also, for context, we discussed the possibility of using branches for each minor version. This works well for long-term maintenance and enterprise support, but is probably too much overhead for us :)

[mimarz]

hmm, yeah. The more I think about it the more I lean towards just having one branch and relying on tags instead. Especially with using changesets.

We can also add some safeguards in workflows, and have routines for production release to always be manual (which we mostly already have).

next releases may then be triggered on push to main and changeset bot.

One caveat could be if someone wants to inspect source code for latest/production version and expects to find it on the main branch. This is a minor thing imho.

In regards to branching out from tag and applying hotfixes on previous versions, we might have some merge conflicts with merging that branch back in after changesets publish PR which bumps version on all packages. But if we just agree on cherry-picking the fix commit back into main instead that and discard the rest, I think that should be ok?

[stianmorsund]

We can also add some safeguards in workflows, and have routines for production release to always be manual (which we mostly already have).

Yes, in my experience you want production releases to be manually triggered

next releases may then be triggered on push to main and changeset bot.

Exactly!

One caveat could be if someone wants to inspect source code for latest/production version and expects to find it on the main branch. This is a minor thing imho.

It would be on main? if you want to inspect the source for a specific version you would just checkout that versions tag. Can you elaborate on this one? :)

In regards to branching out from tag and applying hotfixes on previous versions, we might have some merge conflicts with merging that branch back in after changesets publish PR which bumps version on all packages. But if we just agree on cherry-picking the fix commit back into main instead that and discard the rest, I think that should be ok?

I think the need for merging the fix back into main would depend on the nature of the fix. If the fix also applies to the next version, then you can cherrypick it into main, if it was specific to a previous version and no longer necessary for next, then there would be no need to merge it back in

[mimarz]

One caveat could be if someone wants to inspect source code for latest/production version and expects to find it on the main branch. This is a minor thing imho.

It would be on main? if you want to inspect the source for a specific version you would just checkout that versions tag. Can you elaborate on this one? :)

Just past experience with open source. Not everyone knows about tags and how they work. I have gotten DMs from people saying they can't find the reason for a bug they had looking at the source code (that we had already fixed but not released).

But this is very edge-case and not something which should affect our decision for CI/CD. We'll just have to educate if it happens :)

In regards to branching out from tag and applying hotfixes on previous versions, we might have some merge conflicts with merging that branch back in after changesets publish PR which bumps version on all packages. But if we just agree on cherry-picking the fix commit back into main instead that and discard the rest, I think that should be ok?

I think the need for merging the fix back into main would depend on the nature of the fix. If the fix also applies to the next version, then you can cherrypick it into main, if it was specific to a previous version and no longer necessary for next, then there would be no need to merge it back in

Aye, I think this should work fine, we as a team just need to be thorough on when this happens.

[stianmorsund]

Sounds great!

Just past experience with open source. Not everyone knows about tags and how they work. I have gotten DMs from people saying they can't find the reason for a bug they had looking at the source code (that we had already fixed but not released). But this is very edge-case and not something which should affect our decision for CI/CD. We'll just have to educate if it happens :)

Good point. I think it would be sufficient for most to look at the releases-section of the repo to figure out which changes are tied to each version though. Regular consumers wouldn't need to worry about tags, it would be mostly for maintainers and collaborators who needs to quickly checkout the source code at a specific version or e.g rollback to a specific version as they are just markers :)