New OSS rule: Do as little work as possible
Dmitrii Kovanikov
Posted on March 26, 2023
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
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
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 😌
Posted on March 26, 2023
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related
June 19, 2024