Closed isaacs closed 3 years ago
When I was refactoring this code (to make a Rust version) I've realized that this feature was not working well, was making age computation complex and inaccurate, and was against the RFC. For a simple package that claims to implement the RFC, a huge RFC-breaking fudge was a bad idea, so it had to go.
Sorry for the churn. I should have bumped major version then. However, now that the damage has been done, reverting the change and creating another major version would only create even more failed tests and upgrade churn for users. So I'm going to keep it as-is.
I understand. Tough call, but you're right, the moment has passed, I suppose. Thanks!
Hey, I completely agree with the justification provided in the README, but dropping support for this option is a breaking change, in the SemVer sense of "a change that requires downstream users to alter their code in order to continue working properly with the library".
This broke a few of my tests, and I now have to go and figure out whether I want to pin the version to 4.0, alter the tests to provide an accurate date header, or just live with the red CI. My case is not so horrible, since it does work fine except in the synthetic edge cases that the test is (no longer) exercising, but it's entirely possible that someone using this library had production code broken as a result.
I recommend reverting this change in a 4.1.1 release, and then re-publishing it in a 5.0.0 release. There are two reasonable ways to do this:
legacy branch
This is the approach I typically use when I am on the other end of an issue like this.
Thereafter, any patches you want to land on the v4 branch (where server date is trusted) you can do on the
v4-legacy
branch, andnpm publish
, without worrying that it clobbers the "real" latest release on npm.revert and re-revert
This is a simpler single-branch approach if you're pretty sure you're not going to ever have to touch v4 again.
And never look back.