In this article, I will use Go language as an example, but the subject can be extended to any software with a large codebase and number of users.
Go development team has just published an interesting article about the need to introduce a math/rand/v2 package
Please have a look:
While it's not a breaking changes, as it's a v2. It's the first time Go is bringing a v2 package ever. So in more than 15 years!
The article explains why they came to this choice. You can see the struggle they faced in the decision. How they iterated to try to fix issue, how what they did cause other problems, and finally why they had no other choice than bringing a v2.
This article is good and remind me another good one.
Here is a status from the last man standing developer of testify. Testify is popular test asserters library in Go. The code is 10 years old. They are working on a v2 for years, and they announced they have to abandon it.
Comment for
#1089
A v2 would please users of v2 because of a cleaner API.
A v2 would please maintainers of v2 who are fed-up with flaws in v1's API (traps).
But v2 will be of no help for users of v1 because that will require migration (even just adding /v2 to every import would be a significant and painful migration). With migration (changing code that works) comes a risk of regression. Testify is a set of frameworks for writing testsuites. A testsuite is one critical piece of a software project to protect against regression. The last thing someone wants is a regression in the testsuite that is supposed to protect against regressions.
So users of v1 who can't afford migration (rewrite cost, regression risk...) will just stay with v1. If v1 is abandoned by Testify maintainers who moved to v2, v1 users will just be orphaned.
Testify is very old and has a ton of users that rely on it. At the time of this post (2023-11-15) pkg.go.dev counts 12,454 public packages dependending on it. But this is only the tip of the iceberg as this doesn't count entreprise code hidden behind walls.
To not orphan users of v1, v1 would have to be maintained along with v2. So what is the benefit for maintainers if they have to maintain both v1 and v2? None: only more work while maintenance resources for v1 is already on shortage.
So, as the current only active maintainer, I'm declaring that v2 will never happen. Or at least a v2 of the github.com/stretchr/testify module with such major breaking changes.
Anyone is free to fork the project under a new module name, using changes proposed here or elsewhere, keeping the Testify spirit. This will let users migrate at their own pace. As a maintainer of Testify I will even gladly bless such a fork(s) by linking from testify's documentation (godoc, README). But there is no sane reason for this to happen with the github.com/stretchr/testify module name (the only reason would be branding, but I reject it as a sane reason). Anyway, with how Go modules work, a v2 would already be a module name change. So proponents of breaking changes must just recognize this and just use a fully separate module name.
In this repo we will just continue to maintain v1.
Forever.
Olivier Mengué (@dolmen), current only active maintainer of Testify.
PS: @Antonboom is doing an amazing work with testifylint. That is a major tool that helps Testify users to avoid v1's traps. More than a v2.
You can see how difficult it is to maintain a software that is old, that have a huge number of users.
Top comments (1)
For further reading, I recommend you this article wrote by @bekahhw
dev.to/opensauced/maintainer-month...