Idea about forcing people to upgrade from v1
tunnckoCore opened this issue · comments
Looking at the version downloads...
It seems that there are still 2.7m on 1.2.6, 1.3m on 1.2.2, and ~700k on 1.2.1 and below.
There are probably a few reasons why:
a) old and forgotten packages / projects with no auto-update, or with pinned version
b) not enough time or willing to read
It may be not looking good, for sure, but why not just make the experiment: Just break them, like exporting empty object or noop.
If someone comes - ok, we'll try to help and upgrade it. If not - we are free to not care about ~3m downloads. I have always been careful with this package, just because of that alone. It's legacy, it's baggage. But I'm sure, by running this experiment, we will definitely decrease this number. Which again is a good thing.
Of course, in a week or a month, we will bump again with recover the things.
If you are reading this, and you are STILL on v1, please comment below!
Thoughts, @jimmywarting @GrosSacASac?
edit: The future of formidable is interesting. And it's probably coming to an end in a year or two. Unless probably one thing could be if we can optimize the parser more. Or just be there for the lagging users, and provide thin helpers and wrappers for the new ones. Tweet: https://twitter.com/3a1fcBx0/status/1601163191589163008
That sounds like a terrible idea, and very bad form in open-source to intentionally break things like that. In open-source ethos, there's no obligation to maintain but there is an ethical obligation to not intentionally break things like this. A move like this could get you blacklisted in communities that find out.
Instead, try marking those versions deprecated in NPM, and then just not maintaining the v1 branch. If the old code is still working for some people, why not just let them continue to have that running code? That's the main point of allowing old versions to remain published.
By publishing a new broken version on a patch-level bump (especially if it's intentionally broken, but even if not) you only further encourage exact version pinning and make the problem worse for the future. This would also severely penalize projects which use formidable as an indirect dependency and who would perhaps like to upgrade but don't have committer control over one of the projects in the middle of that dependency chain (and maybe the folks who do don't have time for active maintenance on things like this, though the deprecation notice would help boost priority in at least some cases).
For what it's worth, this package itself has several dependencies that are multiple major versions out of date with what's currently published. Would we appreciate it if developers of those packages suddenly broke things so as to "encourage" dependent projects to upgrade in a scramble, especially during a holiday period? Let's not do that to anybody else.
if you want to make a minor (bug) patch that just export an empty object/noop function than that would be a bad idea.
I would rather just make a deprication notice on npm
npm deprecate <pkg>[@<version range>] "new update are available"npm deprecate <pkg>[@<version range>] "resort to using await request.formData()" instead
this is okey to do if you have ended some long time support and will no longer do any back-port / bug fixes to your old versions
or: it has any security issues. that you simply just don't want to make a patch/bug fix for.
Agree with wbt
@jimmywarting yea. Everything below v2 is deprecated for years already, and they don't migrate.
@wbt totally agree. They are deprecated. The deprecation path seems to not work for us. This crazy idea is at least a way to raise a bit of attention and awareness. I have pretty valid reasons, which I cannot share, why I want them to switch/upgrade as fast as possible. It's for their good.
I strongly believe in open source, and I'm doing it for the past 8 years (less and less in the past 2-3).
Well aware of everything.
If they use ^ as it's by default, then it won't be a problem for anyone because we will publish one more version after the broken one. It could be just a week (or weekend) experiment. Not a big deal.
If they don't, and they use pinned versions, which I suppose is the case, then they won't be affected anyway.
The whole point is to see how much are legacy and dead, so we can ignore them and sleep well; and how much are real and have a reason to not upgrade - so they'll come, and we'll help.
I only see positives, or at least it's better than just staying ignorant like them, and not knowing your userbase or the statistics, and letting them stay in danger.
It's exactly because of accountability and responsibility, and because I care, not the opposite. Open source is built on trust and good will, if just a handful of people wanted, they could literally break the whole internet for a looong time.
If I, we, were bad actors, we wouldn't talk now. I have always done it for helping people and for a greater good. But it's hurting me when I see them lagging, and in danger, just because they are ignorant. I can't allow that.
I'm not doing "just 'cause", and because I don't have anything else to do.
Would we appreciate it if developers of those packages suddenly broke things so as to "encourage" dependent projects to upgrade in a scramble
Yes. That's why v2.1 was published. Because security problems of old packages.
-- tck
The deprecation path seems to not work for us.
Why not? That seems to be the real concern.
But it's hurting me when I see them lagging, and in danger, just because they are ignorant. I can't allow that.
Why then are you OK with this package having several dependencies that are not on their current major versions?
NPM has deprecation warnings and security warnings; GitHub also has security warnings through dependabot (whether you sign up for them or not). If v1 is deprecated and/or vulnerable, those seem like the proper channels to use.
Also keep in mind that with defense-in-depth, vulnerabilities are not necessarily exploitable in any given application, and the context in which an application is used matters a lot.