Adding tags/releases to the repository

[CodingAleCR]

Hi all!

First things first, great work for keeping the repository as up to date as possible not only with good practices but also with dependencies and everything around them. It really makes life a bit easier. Kudos for that!

I've read the Managing Updates guide and while I like the way everything is explained with one exception. I think it would add value to do Github tags or releases for updates within Epic Stack.

The reason for this is that navigating through commit history can become difficult once there is a substantial amount of commits after you generate the code for your project. You can easily apply the changes in a few commits to your project, but when it becomes "too outdated" or there are commits that come in later to fix a certain issue, it becomes really difficult to keep track of what files to update and what files to avoid.

My scenario was upgrading to conform v1, which is fine, and with their guide and the commit/PR done here, I've managed to do it reasonably quickly and the app is running stable. But it definitely would have helped to have a way to compare what I've got (a specific commit) against a tag or something that indicates the current state of things. I know that I could compare the commit from when I created my project and compare it to main and that might do things, but TBH one would have to search through CLI code or something to find the exact commit used as base project and then it becomes a lot harder to update stuff.

In any case, thank you for considering it! Have a great rest of your day/night/morning/evening.

[kentcdodds]

Would we just make a tag for every commit? I just don't know how to version this in a way that's more helpful than the commit history.

[CodingAleCR]

I think there's different ways you could go about it. One could be every to tag commit but I guess that's the same as commit history, another one could be to tag just the updates to the libraries, that way you could easily link packages versions to the version of epic stack.

But if it were me, I think I'd go for something like scheduled releases and treat anything in between as "pre-releases" or something like that. That way you get a cadence for releases which makes it predictable for users of the stack and also it becomes something that doesn't interfere too much with the current workflow (this is an assumption ofc).

Something like quarterly tags/releases feels about right since it's not that big of a time period to allow big major upgrades accumulate too much but also it's not that small of a time period to make the whole thing become too similar to just watching the commit history. It'd also be easier to do partial upgrades. Like instead of updating to the latest and greatest, you could choose a tag that might not be the latest but comes close to it or solves some critical security issue.

Hopefully my ideas make sense to everyone 🤞🏼

[kinggoesgaming]

I think a good way to mark releases would be anytime features are added/removed, core dependencies are updated *@remix-run/*, react, react-dom, etc). This allows a fairly regular version cycle without it being tied to a schedule.

[rperon]

Hi,

I really like your proposition.
One way, we could do that is by adding changesets.
This will add a Changelog and make it easier to create tags / release.

Ideally, each commit on main should contain a changeset file, it won't disturb too much the current workflow and when there is significant changes, Kent can create a release.

What do you think ?

[andrecasal]

I think a good way to mark releases would be anytime features are added/removed, core dependencies are updated *@remix-run/*, react, react-dom, etc). This allows a fairly regular version cycle without it being tied to a schedule.

I like this idea 👍

[kentcdodds]

Ok, I think I can create releases occasionally for significant changes (stuff I've been using announcements for in discussions). But I won't make a release if I'm just updating package.json or fixing a typo.

Thanks!