DEV Community

Dmitrii Kovanikov
Dmitrii Kovanikov

Posted on • Edited on

New OSS rule: Do as little work as possible

With time, my views on how to do OSS changed.

Previously, my motto was:

💪 Do this extra bit of work, so you won't be ashamed of the quality of your OSS projects

Now, I'm more like:

🦥 Choose the approach that requires you to do as less work as possible

I'll give an example of this.


So, in Haskell, versions of the standard library base are tightly coupled with the versions of the compiler GHC:

  • base-4.17.0.0 goes with GHC 9.4
  • base-4.18.0.0 goes with GHC 9.6
  • base-4.19.0.0 goes with GHC 9.8

and so on.

Previously, I always specified tight lower and upper bounds on base in my project configurations, e.g.

build-depends:
  , base > 4.15 & < 4.19
Enter fullscreen mode Exit fullscreen mode

And it was done precisely due to this way of thinking: "do this extra work for extra quality".

You see, I didn't want users of my Haskell packages to compile it with the new GHC version (and a new version of base) and see errors.

They would think that my project is bad, which is not! It's Haskell who's bad for breaking my stuff!! But users don't know that. So my reputation would suffer.

Instead, I specified tight upper bounds on base, so I could say:

🙅 "You can't build my project because it doesn't explicitly support the new compiler version. I'll support it when I have time. Period."

As you can imagine, this resulted in HUGE, GIGANTIC, UNACCEPTABLE amount of work, like holy f*** 🤯🗻

For 40 packages and 3 releases of GHC, I had to open 120 PRs over time (sick !!!).

No wonder I burnt out 😮‍💨


Now, there's a solution. Versions of base in Haskell probably always will be in a form like 4.*. So I can specify the upper bound like this:

build-depends:
  , base > 4.15 & < 5
Enter fullscreen mode Exit fullscreen mode

And forget about ever updating upper bounds!

In fact, this is rather common practice in the Haskell community, and lots of packages already do this stuff. But it took me a while to get here.

This approach means that if there're no breaking changes in either base or GHC, my package will continue building. And I don't have to do anything to support a new version!

If something breaks, somebody will open an issue in my GitHub repository. But I still don't have to do anything, I can just ignore it for the time being! And I can support the new version when I have the time.

So it's a win-win.


This approach is partially inspired by my recent usage of the pretty-terminal Haskell library.

It's first and only version was uploaded to Hackage in 2018 (5 years ago), and it still works without requiring any changes to it!

Now, that must feel good 😌

Top comments (0)