Idea about forcing people to upgrade from v1

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

[wbt]

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.

[wbt]

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.