RFC: Fourmolu breaking changes policy

#1

A recent PR brought up the need for a clear policy around breaking changes in Fourmolu. I’ve opened up a PR documenting the options, the trade-offs, and the context: RFC: Add policy for breaking changes by brandonchinn178 · Pull Request #430 · fourmolu/fourmolu · GitHub

If you use Fourmolu, please take a look and leave a comment.

Key questions:

  • Would the transition period in the proposed policy actually be helpful for you? Would you defer reformatting until a later point, or just the bite the bullet on upgrade (if you’re gonna have to bite the bullet at some point anyway)?
  • Is there another policy you’d think worth adding to the discussion?
1 Like
#2

To be very honest, I see changes in formatters as part of programming life. Whether one is updating a formatter, going from no formatter to some formatter, switching to a different formatter, or even just changing a setting: a reformat of the codebase will often be needed.

Reformats generally do generate conflicts in open pull requests, but then again they don’t tend to be the hardest ones to solve. It’s a little bit annoying, but to me not much more than that. I’ve worked with code reformats often enough now to have built up the speed to deal with them swiftly.

I don’t think I would benefit much from a transition period. I also don’t think I would be hurt by it. So both options are perfectly fine for me.

1 Like
#3

The biggest thing in my mind would be that it is very obvious that an upgrade will be a breaking change. For example, never have a breaking change until you make a major version bump, so that anyone can update/upgrade fourmolu without breaking changes as long as it’s only minor updates?

#4

I think that just moves the problem. The question then becomes “when is it ok to make a major version bump?”. It doesn’t solve the underlying issue of someone being forced to upgrade Fourmolu (e.g. new GHC version), and the upgrade crosses a major GHC version.

I guess one option is to have LTS branches and backport GHC upgrades. But that’s even more maintenance overhead than backwards compat flags. And a sufficiently motivated user could always fork fourmolu themselves and backport the ormolu ghc upgrade.

#5

Ah, ok, fair.

In my mind a transition period won’t do much.
On our production code base, we use a pinned version of fourmolu, and will probably bump it whenever we have to. If we do have to, we’ll just coordinate the reformat as best we can and then pin that version.

So we’d fall into the “we’ll just bite the bullet when we have to” category.

2 Likes