llakala
commented
1 week ago Even once I swap to conventional commits, I still need to decide how to actually handle versions. My instinct is that I'd prefer to use a branch-based model rather than orienting around releases. Currently, this script doesn't JUST serve me (shoutout to @NovaViper). This means we need some degree of safety in a branch - breaking changes should only come when you update to a new branch.
I also want to ensure this is easy as a developer. Ideally, I should be maintaining one branch at any time. Having to constantly move changes between branches seems annoying. With this in mind, I think staying on a branch until we have breaking changes makes sense.
Here's an example. We're on release Inkay, and my entire userbase (with a gargantuan size of two users including me) are pointing to the Inkay branch in their flake inputs. But, I need to make a breaking change, so I make a new Jolteon branch, and work on it from now on. Inkay won't receive any more updates.
I like this from a developer perspective, and it's safe as a user. But, you have to constantly be updating your flake inputs if you want to be tracking the latest changes. It also leads to a lot of dead branches from old releases.
We could solve this through a slight modification, where we maintain an Inkay and an Arceus branch. The Arceus branch would track the current release automatically, so you don't have to constantly be swapping releases. This seems great to me. However, from what I've seen, an automated way to do this doesn't exist. I'll have to constantly be syncing commits between both manually.
The ideal branching strategy is:
- Easy as a developer (only have to work on one branch at a time)
- Safe as a user (your config shouldn't break after updating your inputs)
- Convenient as a user (you can choose to live on the edge if you want)
Typical branching strategies are Easy and Convenient, but not Safe, since they don't provide an easy way to manage breaking changes. The strategy I described first with only working on Inkay is Easy and Safe, but not convenient. The second strategy with Inkay AND Arceus is Safe and Convenient, but not Easy since it sucks to maintain.
Looking back, it seems like I've reinvented the wheel, and have converged on Releases as the best versioning scheme. But I'll dispute that a bit. Releases, at least in theory, are immutable. I like branches because they're continually supported. I can hypothetically do that via lots of point releases, but that's annoying as a developer. We want it to be Easy, and a branch is easy.
I want to write more, but it's my time to bow out for the night. Hopefully I'll return with an Easy, Safe, and Convenient branching scheme.
Just had my first breaking change, and it's made me realize we need a way to separate breaking and non-breaking changes. I think a good way of getting started here is to implement Conventional Commits. I'm already almost doing them, since I try to start each commit with its scope. I just need to also include the type of commit. I've been wanting to do this in my configuration for ages, so I can start here.
For an intro on Conventional Commits, check out this wonderful writeup.