Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Converge on a versioning scheme #18

Open
llakala opened this issue Nov 20, 2024 · 1 comment
Open

Converge on a versioning scheme #18

llakala opened this issue Nov 20, 2024 · 1 comment

Comments

@llakala
Copy link
Owner

llakala commented Nov 20, 2024

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.

@llakala llakala pinned this issue Nov 20, 2024
@llakala
Copy link
Owner Author

llakala commented Nov 20, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant